Closed Rafaelki closed 9 months ago
Our sample web part has a pending PR that is awaiting @sebastienlevert to approve it when he returns from his much deserved holiday.
It looks like you haven't included the necessary change to the SPFx build chain to correctly process es2021 JavaScript, which one of our deps is now shipping with.
If you pull from the sample repo and checkout feat/update-spfx-for-v4
then that will build, at least it did for me using npm, I've not tested it with pnpm.
Thanks @gavinbarron for your quick response. Is that because the SPFx toolchain is a bit outdated?
I have included the libraries in the package.json and copied the gulpfile and I am able to bundle and serve. I think the first time takes the webpack tasks a bit longer than before (2 minutes), but after that it is ok, does it make sense?
Installing with pnpm, the bundle produces the same error:
Error - [webpack] 'dist':
./node_modules/.pnpm/lit-html@3.1.2/node_modules/lit-html/directives/class-map.js 6:106
Module parse failed: Unexpected token (6:106)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
Could this be due to any phantom dependencies to lit?
@Rafaelki happy to help and that it's a somewhat solved problem.
Yeah, the SPFx toolchain is a bit outdated. It's still on webpack 4, which is why we need to pull in those specific transforms. The time to bundle there is significantly longer than I experience, but that might be due to hardware and system pressures you have.
Looking at the error you have there I think I see the problem. In the gulp file we have includes like this path.resolve(__dirname, "./node_modules/lit-html")
but your error message when using pnpm has the path ./node_modules/.pnpm/lit-html@3.1.2/node_modules/lit-html/directives/class-map.js
Perhaps updating the includes to have the paths like path.resolve(__dirname, "./node_modules/.pnpm/lit-html")
might fix this problem?
If I look at the code in classMap.js I can see that the symbol at 6:106 is an optional chaining operator, t.strings?.length
, which supports the theory that the babel loader is not processing this file due to the differing path when using pnpm.
Thanks @gavinbarron . adding /.pnpm works perfectly, thanks a lot
That's fantastic news! Thank you for confirming. I'm going to add some documentation to call this out,
Scratch that, I'm going to update the sample app with the newer version of the webpack modification that I came up with as the function form works for both package managers.
const litFolders = ['node_modules/lit/', 'node_modules/@lit/', 'node_modules/lit-html/'];
build.configureWebpack.mergeConfig({
additionalConfiguration: generatedConfiguration => {
generatedConfiguration.module.rules.push({
test: /\.js$/,
// only run on lit packages
include: resourcePath =>
litFolders.some(litFolder => resourcePath.includes(litFolder)),
use: {
loader: 'babel-loader',
options: {
plugins: [
'@babel/plugin-transform-optional-chaining',
'@babel/plugin-transform-nullish-coalescing-operator',
'@babel/plugin-transform-logical-assignment-operators'
]
}
}
});
return generatedConfiguration;
}
});
Closing this now that we have resolved the issue.
ERROR: Module parse failed: Unexpected token (59:58) You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders | */ | try {
if (bridgeProxy.getHostCapabilities()?.queryAccount) {
| this.activeAccount = | await bridgeProxy.getActiveAccount();
CALL STACK: Error: Module parse failed: Unexpected token (59:58) You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders | */ | try {
if (bridgeProxy.getHostCapabilities()?.queryAccount) {
| this.activeAccount = | await bridgeProxy.getActiveAccount(); at Obj/ (https://localhost:4321/dist/demo-web-part.js:1345:7) at webpack_require (https://localhost:4321/dist/demo-web-part.js:64:30) at Object.Eo22 (https://localhost:4321/dist/demo-web-part.js:891:104) at webpack_require (https://localhost:4321/dist/demo-web-part.js:64:30) at 5xBa (https://localhost:4321/dist/demo-web-part.js:370:92) at webpack_require (https://localhost:4321/dist/demo-web-part.js:64:30) at Module.wj7Y (https://localhost:4321/dist/demo-web-part.js:2475:77) at webpack_require (https://localhost:4321/dist/demo-web-part.js:64:30) at https://localhost:4321/dist/demo-web-part.js:229:18 at https://localhost:4321/dist/demo-web-part.js:232:10
I am getting this error for @azure/msal-browser
This is my webpart code
import * as React from 'react';
import as ReactDom from 'react-dom'; import { Version } from '@microsoft/sp-core-library'; import { BaseClientSideWebPart } from '@microsoft/sp-webpart-base'; import as msal from '@azure/msal-browser';
import Exm from './components/Exm'; import { MsalProvider } from '@azure/msal-react';
const msalConfig:msal.Configuration = { auth: { clientId: '', authority: '', redirectUri: 'https://bayergroup.sharepoint.com/_layouts/workbench.aspx' }, system: { iframeHashTimeout: 10000, loggerOptions: { loggerCallback: (level, message, containsPii) => { if (containsPii) { return; } switch (level) { case msal.LogLevel.Error: console.error(message); return; case msal.LogLevel.Info: console.info(message); return; case msal.LogLevel.Verbose: console.debug(message); return; case msal.LogLevel.Warning: console.warn(message); return; } }, }, }, }; const msalInstance: msal.PublicClientApplication = new msal.PublicClientApplication(msalConfig);
export default class DemoWebPart extends BaseClientSideWebPart
public render(): void {
const element: React.ReactElement
ReactDom.render(element, this.domElement);
}
protected onDispose(): void { ReactDom.unmountComponentAtNode(this.domElement); }
protected get dataVersion(): Version { return Version.parse('1.0'); } } How to resolve this?
@tarun-bayer123
I'm having a hard time understanding where this issue is coming from. In a SharePoint web part the usual practice is to use the SharePoint provider as documented. Perhaps try adding the package from which the file causing this error is in to the include list in the gulpfile modification.
Hi @gavinbarron,
I tried using the function approach for webpack modification and it is still throwing the same error when using with pnpm.
const litFolders = [ "node_modules/lit/", "node_modules/@lit/", "node_modules/lit-html/", "node_modules/.pnpm/lit/", "node_modules/.pnpm/@lit/", "node_modules/.pnpm/lit-html/" ]; build.configureWebpack.mergeConfig({ additionalConfiguration: generatedConfiguration => { generatedConfiguration.module.rules.push({ test: /.js$/, // only run on lit packages in the root node_module folder include: resourcePath => litFolders.some(litFolder => resourcePath.includes(litFolder)), use: { loader: "babel-loader", options: { plugins: [ "@babel/plugin-transform-optional-chaining", "@babel/plugin-transform-nullish-coalescing-operator", "@babel/plugin-transform-logical-assignment-operators" ] } } }); return generatedConfiguration; } });
However it works fine with earlier approach and changing the the path to "./node_modules/.pnpm/@lit". Am I missing anything here?
Thanks!
Here's the error I'm getting when running the latest sample:
Error - [webpack] 'dist':
./node_modules/lit-element/lit-element.js 6:194
Module parse failed: Unexpected token (6:194)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
| * Copyright 2017 Google LLC
| * SPDX-License-Identifier: BSD-3-Clause
> */class s extends t{constructor(){super(...arguments),this.renderOptions={host:this},this._$Do=void 0}createRenderRoot(){const t=super.createRenderRoot();return this.renderOptions.renderBefore??=t.firstChild,t}update(t){const i=this.render();this.hasUpdated||(this.renderOptions.isConnected=this.isConnected),super.update(t),this._$Do=e(i,this.renderRoot,this.renderOptions)}connectedCallback(){super.connectedCallback(),this._$Do?.setConnected(!0)}disconnectedCallback(){super.disconnectedCallback(),this._$Do?.setConnected(!1)}render(){return i}}s._$litElement$=!0,s[("finalized","finalized")]=!0,globalThis.litElementHydrateSupport?.({LitElement:s});const r=globalThis.litElementPolyfillSupport;r?.({LitElement:s});const o={_$AK:(t,e,i)=>{t._$AK(e,i)},_$AL:t=>t._$AL};(globalThis.litElementVersions??=[]).push("4.0.4");export{s as LitElement,o as _$LE};
| //# sourceMappingURL=lit-element.js.map
|
@ ./node_modules/lit/index.js 3:0-43 3:0-43
@ ./node_modules/@microsoft/mgt-element/dist/es6/components/baseComponent.js
@ ./node_modules/@microsoft/mgt-element/dist/es6/index.js
@ ./lib/webparts/mgtDemo/MgtDemoWebPart.js
I added the following to the the litFolders in the gulpfile.js which seeems to work now:
`node_modules${path.sep}lit-element${path.sep}`,
Describe the bug SPFx 1.18 and MGT 4 throw an error while bundling, which I think is related to LIT.
To Reproduce Steps to reproduce the behavior:
Expected behavior The sample code should bundle without errors.
Screenshots