This post was most recently updated on November 19th, 2019.Reading Time: 7 minutes.
This post describes the typical reasons why might encounter the following error, and the ways I’ve found to fix them: “Failed to load component. Original error: ***Failed to load path dependency ContosoSPFxWebPartLocalization from component [guid] (ContosoSPFxWebPart)”
The error typically looks something like in the screenshot below:
This error can be thrown for a lot of different reasons. I’m trying to describe the variants I’ve run into and their fixes below. But first, let’s take a closer look into the error in question!
So looking at this, what’re the actual errors we’re getting? Where are they stemming from?
From the first line (“SPLoaderError.loadComponentError“) we already know that it’s about the SPFx failing to load your component for whatever reason. Now all that’s left is figuring out what the reason is!
I’ve seen a few different variations out of this error. Sometimes you have the sick-looking “https://component-id.invalid…” -url, sometimes you see an absolute url – let’s take a closer look at the stack below!
[SPLoaderError.loadComponentError]: ***Failed to load component "9951b316-c8f2-4e27-887a-b7a46b3e94a0" (ContosoSPFxWebPart). Original error: ***Failed to load path dependency "ContosoSPFxWebPartLocalization" from component "9951b316-c8f2-4e27-887a-b7a46b3e94a0" (ContosoSPFxWebPart). Original error: Error loading https://component-id.invalid/9951b316-c8f2-4e27-887a-b7a46b3e94a0_1.3.1/ContosoSPFxWebPartLocalization Unable to load script https://contoso.sharepoint.com/sites/contosoapps/ClientSideAssets/490f3be2-7e8a-4fe5-8d6b-49ae5d7c4a2e/s-ContosoSPFxWebPartLocalization_en-us_2b301efaa958eadafbad865f710d89e4.js ***INNERERROR: ***Failed to load path dependency "ContosoSPFxWebPartLocalization" from component "9951b316-c8f2-4e27-887a-b7a46b3e94a0" (ContosoSPFxWebPart). Original error: Error loading https://component-id.invalid/9951b316-c8f2-4e27-887a-b7a46b3e94a0_1.3.1/ContosoSPFxWebPartLocalization Unable to load script https://contoso.sharepoint.com/sites/contosoapps/ClientSideAssets/490f3be2-7e8a-4fe5-8d6b-49ae5d7c4a2e/s-ContosoSPFxWebPartLocalization_en-us_2b301efaa958eadafbad865f710d89e4.js ***CALLSTACK: Error at t [as constructor] (https://spoprod-a.akamaihd.net/files/sp-client-prod_2019-03-15.008/sp-pages-assembly_en-us_2676c0dcef2e33d08d5b8433ef878499.js:889:16049) at new t (https://spoprod-a.akamaihd.net/files/sp-client-prod_2019-03-15.008/sp-pages-assembly_en-us_2676c0dcef2e33d08d5b8433ef878499.js:1512:21125) at Function.e.buildErrorWithVerboseLog (https://spoprod-a.akamaihd.net/files/sp-client-prod_2019-03-15.008/sp-pages-assembly_en-us_2676c0dcef2e33d08d5b8433ef878499.js:1512:16214) at Function.e.buildLoadComponentError (https://spoprod-a.akamaihd.net/files/sp-client-prod_2019-03-15.008/sp-pages-assembly_en-us_2676c0dcef2e33d08d5b8433ef878499.js:1512:12245) at https://spoprod-a.akamaihd.net/files/sp-client-prod_2019-03-15.008/sp-pages-assembly_en-us_2676c0dcef2e33d08d5b8433ef878499.js:1512:60385
You’ll be interested in a couple of things here. The first line we’re already familiar with (SPLoaderError.loadComponentError), so now we’ll take a look at 2 different interesting things.
First of all, we can identify the faulting components by investigating the component IDs – probably, the most interesting line is the INNERERROR:
***Failed to load path dependency “ContosoSPFxWebPartLocalization” from component “9951b316-c8f2-4e27-887a-b7a46b3e94a0” (ContosoSPFxWebPart).
The name of the dependency tells you, which component, bundle or file the Loader is failing to load. This will of course help you identify which of your imports fails if you’re the one developing the solution.
Other interesting part is the url where the Loader is trying to load the dependencies from. Take a look at the example below:
Unable to load script https://contoso.sharepoint.com/sites/contosoapps/ClientSideAssets/490f3be2-7e8a-4fe5-8d6b-49ae5d7c4a2e/s-ContosoSPFxWebPartLocalization_en-us_2b301efaa958eadafbad865f710d89e4.js
Take another look at that url and make a mental note of it – you’ll need it soon.
Reasons and solutions
Okay, so after a bit of digging, there are a couple of different reasons and different solutions. First thing we need to figure out, is to find the deployment path for your solution. It’s likely either the SharePoint CDN, or a path under the App Catalog in SharePoint Online. However, it’s also possible to host the files your .sppkg or .app file then requests in pretty much any location!
Anyway – let’s verify if you’re using CDN or not. Take a look at the error to find the url the script is being loaded from – does it begin with something like this:
If it does, you likely have an SPFx webpart that’s deployed to the public Office 365 CDN.
While you might have additional resources loaded from CDN, these domains are typically not hosting your components:
These are additional resources or core components being loaded from different CDN services. Yes, Microsoft has quite a few of them :)
If you’re not using CDN, skip the next subchapter and jump right to “Error in dependencies or packaging“.
Errors with CDN
This solution only applies if you’re using Office 365 CDN.
Does the error apply to just one SPFx package or to multiple? If it applies to all of the SPFx packages that are deployed to CDN on that tenant, it’s somewhat safe to assume that the CDN is to blame.
While using Office 365 is definitely the suggested course of action most of the time, it’s worth realizing that the CDN is not the most stable piece of tech ever existed. The built-in CDN has had its fair share of issues – see the ones below for examples:
A lot of times, these issues are fixed by one of the following actions (these are very unofficial and totally made up by me, by the way):
How to fix Office 365 CDN when it breaks?
- Make sure you have enabled CDN for this tenant.
- Wait for about 15 minutes.
- Verify that you have */ClientSideAssets set as a private CDN origin.
- Deploy an updated version of your sppkg package.
- Remove your existing packages (only if you know you can do that on this tenant!), also from the recycle bin in the app catalog site, then upload your package again.
- Open a ticket at Microsoft Support complaining about this case and reference the suitable GitHub issues in it.
These steps apply to both the error described in this article, but also cases when your app just won’t update.
To verify that you have a CDN origin configured properly, run this and verify the origin exists (see picture below):
Connect-PnpOnline Get-PnPTenantCdnOrigin -CdnType "Public"
Error in dependencies or packaging
If you’re encountering this with your own package in development, grab the component name and/or the Guid. The component name will help you pinpoint which one of your imports is being misconstructed.
Now, if it indeed is YOUR package, fix it somehow like this: http://www.ktskumar.com/2018/01/failed-load-component-sharepoint-framework/
You could also try running gulp clean and rebuild, something like this:
gulp clean gulp build gulp bundle --ship gulp package-solution --ship
This issue only exists in Internet Explorer…
Oh, how I would love to tell you to stop using Internet Explorer… But I know, I know – maybe your customer requires it.
Anyhow, these are some of the extra things you can try with IE:
- Force IE to use 11 document mode
- IE 10 or compatibility mode is not supported. If you have to, modify the master page to get IE to behave properly.
- Set your site and CDN to be on the same security zone
- Shouldn’t matter – but it still does. Duh.
- Go through your dependencies once more
- There’s a TON of dependencies, that might not be compatible with legacy browsers. Verify, that you’re not using something that doesn’t work with IE at all!
- This applies especially if you get the threaded error below:
[SPLoaderError.loadComponentError]: ***Failed to load component "58c4fb68-60f1-45ac-b057-ba7cc51c3ec2" (WebPartName). Original error: ***Failed to load URL 'https://publiccdn.sharepointonline.com/tenantname.sharepoint.com/sites/AppCatalogName/ClientSideAssets/ca2eacd0-4645-4306-a335-e5d9aa919578/web-part-name_e437798e9f3bcfff6ee74118a0bf73ed.js' for resource 'web-part-name' in component '58c4fb68-60f1-45ac-b057-ba7cc51c3ec2' (WebPartName). There was a network problem. This may be a problem with a HTTPS certificate. Make sure you have the right certificate.
Another quick note about the error above – also verify that your system time is correct – if not, you might run into funny SSL certificate errors… :)
Is it not your package? Check the solutions below, and if none of them resolve your issue, ask whomever you got the package from, if the package is working for everyone else.
Error with External/Guest users
Okay, sounds pretty broad, right? But I’ve found 2 different solutions here. These solutions apply to AT LEAST the situations when your internal users don’t necessarily experience the issues at all, but your external/guest users do.
Not using CDN?
If you’re not using CDN with your SPFx webparts, most likely they’re hosted from your app catalog’s SiteAssets/ClientSideAssets library. If you have external users accessing your site, they won’t by default be able to access this site at all, and will hence encounter weird issues with the SPFx webparts.
In a case like this, you have at least two different options:
How to enable your external users to access your SPFx webparts that are not hosted on CDN:
- Enable CDN and deploy your apps there instead of the app catalog
- See my snippet on how to do that: How to fix Office 365 CDN when it breaks?
- Modify the ClientSideAssets -library’s permissions in the app catalog site to allow external users access there. This includes at least the following steps.
- Enable external sharing on your tenant if it isn’t enabled already.
- Enable external sharing on the App Catalog site
- Invite a group with your external/guest users to the ClientSideAssets library as visitors/readers.
As a side note, to enable hosting your SPFx solution from SharePoint, you need to have “includeClientSideAssets” as “true” in the package-solution.json file. This configuration is also typically ignored when building debug builds (bundle without –ship).
Using CDN and messing up the permissions
In a case like this, it’s probably not you, it’s Microsoft. There isn’t that much you can mess up with CDN that would be external users -specific. And if you have, I want to hear about that, so please do leave a comment below!
Otherwise, to try and fix the CDN, see my steps for Office 365 CDN tweaking here.
More info about Office 365 CDN:
If you want to read more on Office 365 CDN, these are a good sources to get started!
He's been a developer from 2004 (starting with PHP and Java), and he's been bending and twisting SharePoint into different shapes since MOSS. Nowadays he's not only working on SharePoint, but also on .NET projects, Azure, Office 365 and a lot of other stuff. He's also Microsoft MVP for Office Development.
This is his personal professional (e.g. professional, but definitely personal) blog.
Latest posts by Antti K. Koskela (see all)
- Classic SharePoint blogs are going away – what next? - December 10, 2019
- How to find out which WebDriver version is installed on an Azure DevOps build machine using YAML? - December 4, 2019
- How to migrate your Delve Blogs content to Modern SharePoint? - November 28, 2019