microsoftgraph / microsoft-graph-toolkit

Authentication Providers and UI components for Microsoft Graph 🦒
https://docs.microsoft.com/graph/toolkit/overview
Other
964 stars 309 forks source link

[BUG] Errors bundling MGT 4 + SPFx 1.18 #3045

Closed Rafaelki closed 9 months ago

Rafaelki commented 9 months ago

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:

  1. Download the latest example of MGT + SPFx from https://github.com/pnp/mgt-samples/tree/main/samples/app/sp-webpart
  2. Run npm i or pnpm i (it fails with both)
  3. Run gulp build and fix the errors related to personCardInteraction, PersonViewType and Tasks
  4. Run gulp bundle
  5. See errors:
    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.

    Expected behavior The sample code should bundle without errors.

Screenshots image

gavinbarron commented 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.

Rafaelki commented 9 months ago

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? image

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?

gavinbarron commented 9 months ago

@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.

Rafaelki commented 9 months ago

Thanks @gavinbarron . adding /.pnpm works perfectly, thanks a lot

gavinbarron commented 9 months ago

That's fantastic news! Thank you for confirming. I'm going to add some documentation to call this out,

gavinbarron commented 9 months ago

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;
  }
});
gavinbarron commented 9 months ago

Closing this now that we have resolved the issue.

tarun-bayer123 commented 9 months ago

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 = React.createElement( MsalProvider, {instance:msalInstance}, Exm );

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?

gavinbarron commented 9 months ago

@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.

akshataggrwal commented 9 months ago

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!

JonoSuave commented 4 months ago

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
JonoSuave commented 4 months ago

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}`,