sp-dev-docs
sp-dev-docs copied to clipboard
SPFx WebPart Dependencies not loaded correctly any more (relative-path.invalid Network Error)
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:

Steps to reproduce
- Create a SPFx WebPart
- In the WebPart manifest.json add "TeamsTab" to "supportedHosts"
- In the config.json add external dependencies like:
"externals": { "handlebars": "./node_modules/handlebars/dist/handlebars.min.js", ... }, - Import and use the dependencies in the WebPart - such as
import * as Handlebars from 'handlebars'; ... private async getFormHtml(formSettings:IFormItem) : Promise<string> { Handlebars.registerHelper({ ... }); ... } - Configure and load the WebPart in the TeamsTab
- 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).
Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.
@chr-sad - thanks for reporting this one. Just to confirm - it's not working with Teams tab only, correct?
@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 - 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?
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:

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

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

@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 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.
This should be rolled out to 100% by now
@AJIXuMuK I can confirm it is working again :) Thank you for your help & investigation and fixing this issue!
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