Sp-dev-docs: Intermittent external dependency loading issues

[wictorwilen]

Category

• [ ] Question
• [ ] Typo
• [X] Bug
• [ ] Additional article idea

Expected or Desired Behavior

When creating a custom JavaScript library to be referenced by an SPFx solution (client side web parts and application customizers etc) I expect that I can reference @microsoft/sp-* modules and therefore be able to create shared code to optimize performance and payload of our SPFx solutions.

Observed Behavior

Adding @microsoft/sp-* npm packages to an external lib and referencing them as externals in the webpack config and then referencing this library in an SPFx project (as external) works in the Workbench, however when deploying the solution to SharePoint the following error is shown when it's trying to load dependencies for the external library:

GET https://relative-path.invalid/@microsoft/sp-loader net::ERR_NAME_NOT_RESOLVED

The define statement in my library looks like this:

define("myawesome-lib", ["@microsoft/sp-loader","@microsoft/sp-http"], function(__WEBPACK_EXTERNAL_MODULE_6__, __WEBPACK_EXTERNAL_MODULE_10__) { return /******/ (function(modules) { // webpackBootstrap 

The error is not always shown, it can sometimes be on an application customizer and sometimes on one or more client side web parts on the page. Cleaning the cache/restarting browser causes it either to work or other components fail to load on next reload.

Steps to Reproduce

Create a new npm library and use and reference any @microsoft/sp-* package as external in the library. Then use this library, as external, in your SPFx project and try to add one or more web parts on a page. As I stated, it does not always happen, but if you want to dig further into a "working" example I can do that off-Github.

[waldekmastykarz]

I wonder if this isn't caused by the fact, that because your library doesn't have an SPFx manifest, SPFx doesn't know how to resolve its external dependencies. The whole thing would be solved by SPFx libraries, which just like web parts and extensions have a manifest that lists external and SPFx dependencies, like @microsoft/sp-http. The problem is, that currently we can't deploy libraries to app catalog, so the only workaround is to include all dependencies which defies the purpose of using libraries.

[wictorwilen]

All the components are loaded on the page and as far as I understand SPFx uses a specific SystemJS implementation that actually detects if it is an SPFx component and then fetches the correct sp-* script. That's also what I see when I step through the code, most of the times it resolves it correctly, but sometimes it just don't

[GrahamMcMynn]

@wictorwilen - thanks for your feedback. We are currently working on improving this experience and should be making changes to help this. When these changes roll out we will follow up to see if it has fixed your issue.

[wictorwilen]

Thanks @mcmynn83. Let me know when you want some testing to be done.

[GrahamMcMynn]

@wictorwilen - sounds good. Just to set expectations, it is still code that is being worked on so it's not in the rollout pipeline yet (ie at best it will be closer to 3-4 weeks, not 1-2).

[wictorwilen]

@mcmynn83 - that's sooner than I expected then :-). Workaround is bundling our stuff now, but I really would like to avoid these huge SPFx payloads and shared code!

[ravinleague]

Guys,
Contributing my two cents.
We did experience issues with loading externals. They were very intermittent. As per our investigation, it was the externals.js file that was experiencing issues with loading external resources. What we did not understand is that SPComponentloader.loadScript('') worked well and it also has a promise so that other scripts can be loaded in order.
We thought, externals.js and SPComponentLoaded are one and the same. However, we stopped using externals.js and were using SPComponentloaded.loadCSS and loadScript for all our external resources.

Thx

[NickSevens]

Is there any progress on this? @wictorwilen did you receive any news/update? I'm still seeing the exact same issue when referencing SPFx packages outside the SPFx project itself.
Thanks

[andrewconnell]

Did you see this get fixed @wictorwilen ? Comment from last year implies a fix was coming in a few weeks which has long since passed...

[msft-github-bot]

This issue has been automatically marked as stale because it has marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within next 7 days of this comment. Thank you for your contributions to SharePoint Developer activities.

[msft-github-bot]

Closing issue due no response from original author. If this issue is still occurring, please open a new issue with additional details. Notice that if you have included another related issue as additional comment on this, please open that also as separate issue, so that we can track it independently.

[msft-github-bot]

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