sp-dev-docs icon indicating copy to clipboard operation
sp-dev-docs copied to clipboard

SPFx WebPart Dependencies not loaded correctly any more (relative-path.invalid Network Error)

Open chr-sad opened this issue 3 years ago • 7 comments

Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

💥 SharePoint Framework

Developer environment

Windows

What browser(s) / client(s) have you tested

  • [ ] 💥 Internet Explorer
  • [ ] 💥 Microsoft Edge
  • [X] 💥 Google Chrome
  • [ ] 💥 FireFox
  • [ ] 💥 Safari
  • [ ] mobile (iOS/iPadOS)
  • [ ] mobile (Android)
  • [ ] not applicable
  • [ ] other (enter in the "Additional environment details" area below)

Additional environment details

  • Google Chrome Version 105.0.5195.127 (64-Bit)
  • SPFx version 1.15.2
  • Node.js version 16.15.1

Describe the bug / error

Since last week we experience that our SPFx WebPart ist not loading correctly any more without changes made to the SPFx solution. The WebPart itself is loading, but it seems if we look in the network tab, that the external dependencies are not loading any more. This is not the case in every scenario - if we host the WebPart directly in a SharePoint Online page as SharePointWebPart or SharePointFullPage, it is loading and working as expected. If we use our WebPart configured as TeamsTab we get network errors and the WebPart is not working because of various errors: image

Steps to reproduce

  1. Create a SPFx WebPart
  2. In the WebPart manifest.json add "TeamsTab" to "supportedHosts"
  3. In the config.json add external dependencies like: "externals": { "handlebars": "./node_modules/handlebars/dist/handlebars.min.js", ... },
  4. Import and use the dependencies in the WebPart - such as import * as Handlebars from 'handlebars'; ... private async getFormHtml(formSettings:IFormItem) : Promise<string> { Handlebars.registerHelper({ ... }); ... }
  5. Configure and load the WebPart in the TeamsTab
  6. Externals will not be loaded with wrong paths in the network tab leading to various script errors: https://relative-path.invalid/ae362d8c-cb6c-4907-ae62-bab91b0250dc_2.1.3/handlebars.js

Expected behavior

SPFx WebParts with external dependencies work in every supported host (all dependencies are loaded correctly).

chr-sad avatar Oct 08 '22 15:10 chr-sad

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

ghost avatar Oct 08 '22 15:10 ghost

@chr-sad - thanks for reporting this one. Just to confirm - it's not working with Teams tab only, correct?

AJIXuMuK avatar Oct 10 '22 13:10 AJIXuMuK

@AJIXuMuK thanks for your fast response. In the Teams tab it is reproducable everytime since multiple days (we tried clear all site data, bypass network in network tools and disable cache and still see the error every time). Some colleagues showed me the same error in SharePoint Online as well, but i was not able to write it down in steps to reproduce so I did not mention it. In these cases our WebPart logic was used as a FormCustomizer. But the exact same WebPart configured as SharePointFullPage did not throw the error so I can not be 100% sure, if it is a problem with our solution. Maybe it is relevant for your investigation: I could see in the requirejs context, that our tenant shows now react 17.x dependencies besides 16.x - mabye it is something related with this rework.

chr-sad avatar Oct 10 '22 13:10 chr-sad

@chr-sad - can I ask you for a simple repro example that contains all your imports and maybe some fake logic that uses the same calls to externals as your actual code?

AJIXuMuK avatar Oct 10 '22 13:10 AJIXuMuK

ExternalsDemo.zip @AJIXuMuK sure, I already created a simple version with most of the dependencies and attached it (ExternalsDemo.zip). But in this case it is working including teams so I have no idea right now, why it is not working in our solution.

In the first case (our solution where we get the error) the dependency "handlebars" is visible in the network tab 2 times - one time it is working, the second time we get the error described in the description above: image

In the second case (the demo solution attached) "handlebars" is visible in the network tab 2 times as well, but both correctly: image

chr-sad avatar Oct 10 '22 15:10 chr-sad

We have tried to remove our solution completely and reinstall it, update the Teams manifest.json according to the latest documentation, remove the Teams app only and upload it manually but nothing changes the behaviour.

chr-sad avatar Oct 13 '22 16:10 chr-sad

ExternalsDemoNotWorking.zip @AJIXuMuK I finally could reproduce the error. It is a combination of externals and webpackChunks which again has references to externals and locales. I attached the updated demo solution which is working in SharePoint but stops working in teams. The demo solution makes no sence at all but is just for reproducing the error-case.

Lines 41-49 in ExternalsAppCustomizerApplicationCustomizer.ts leads to the errors mentioned:

   public getExternalLoader = async () =>
   {
     //TODO this kills the solution in teams and forms customizer (need to fix)
     const externalLoader = await import(
       /* webpackChunkName: 'sample-externalloader' */
       '../../common/SampleExternalsLoader'
     );

     return externalLoader.SampleExternalsLoader.getInstance();
   }

If we do not use webpackChunks in this place it works everywhere, but increases the bundle size. You can see the behaviour working in SharePoint using the WebPart by clicking the button "Click me for external loader sample".

chr-sad avatar Oct 18 '22 08:10 chr-sad

@AJIXuMuK do you have any news on this topic? Is it a bug or not supported to have webpack chunks referencing again externals?

chr-sad avatar Oct 26 '22 11:10 chr-sad

@chr-sad - I was able to repro it with your test solution. We will be investigating it. Will get back to you as soon as there are any updates.

AJIXuMuK avatar Nov 02 '22 15:11 AJIXuMuK

@chr-sad - that was a very interesting bug to address. Thank you for the sample - it helped a lot! The issue has been addressed and will be rolled out in the next couple of weeks.

One question though. Are you using application customizer to initialize some globals in real project too? If yes - why did you decide to do that instead of SPFx library components?

AJIXuMuK avatar Nov 04 '22 13:11 AJIXuMuK

@AJIXuMuK thank you so much for taking care of this issue and fixing it! :) Is it possible to get an update on this issue when it is rolled out globally?

Yes, we are using some globals as well. We have developed two pro-code modules (c4.forms for custom forms and c4.data for custom data visualization) that work individually, but also in combination. The modules themselves know nothing about each other and are completely independent. We had to find a way to make the modules interact with each other in configuration-time / runtime (not in SPFx solution creation time) when both are installed, and found no other way to achieve this.

Here is a small gif (only in german, sorry for that) for illustration. You see one c4.form spfx fullpage-webpart hosting a c4.data module for displaying a list which then opens another c4.form as a side panel - the global is used for communication: image

chr-sad avatar Nov 04 '22 16:11 chr-sad

@chr-sad - I will communicate when the fix is rolled out.

Regarding multiple components: the main question I have is why you decided to use global that are instantiated in application customizer instead of using SPFx Library component that can be referenced/imported in any other SPFx solution on the tenant.

AJIXuMuK avatar Nov 04 '22 17:11 AJIXuMuK

@AJIXuMuK good question - I just read the current documentation of library components, maybe it would be possible with them as well now, thanks for pointing this out. I will have to check this topic in detail again.

chr-sad avatar Nov 04 '22 17:11 chr-sad

This should be rolled out to 100% by now

AJIXuMuK avatar Nov 23 '22 17:11 AJIXuMuK

@AJIXuMuK I can confirm it is working again :) Thank you for your help & investigation and fixing this issue!

chr-sad avatar Nov 24 '22 07:11 chr-sad

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues

ghost avatar Dec 01 '22 12:12 ghost