Sp-dev-docs: Refering external JavaScript libraries from CDN not working for spfx

Created on 10 Jul 2018  路  12Comments  路  Source: SharePoint/sp-dev-docs

The issue is raised here : https://github.com/pnp/pnpjs/issues/158
This is what i did
"externals": { "@pnp/logging": "https://cdnjs.cloudflare.com/ajax/libs/pnp-logging/1.1.2-2/logging.es5.umd.min.js", "@pnp/common": "https://cdnjs.cloudflare.com/ajax/libs/pnp-common/1.1.2-2/common.es5.umd.min.js", "@pnp/odata": "https://cdnjs.cloudflare.com/ajax/libs/pnp-odata/1.1.2-2/odata.es5.umd.min.js", "@pnp/sp": "https://cdnjs.cloudflare.com/ajax/libs/pnp-sp/1.1.2-2/sp.es5.umd.min.js" },

image

but at the end i get this error , it is not working
image
image

spfx-general tracked bug-suspected

Most helpful comment

We are working on a solution here. A couple of moving pieces and we want to avoid a hacky workaround.

All 12 comments

@VesaJuvonen - this doesn't appear to be something with the CDN, but rather something in the packaging steps.

Edit: Specifically these instructions: https://docs.microsoft.com/en-us/sharepoint/dev/spfx/web-parts/basics/add-an-external-library#load-a-script-from-a-cdn

Am I missing something @VesaJuvonen

Any update on this?

experiencing the same issue with a spfx 1.5.1 project (2 extensions and 3 webparts)

@harshdamaniahd Using an external JavaScript library requires that the library require all of it's dependencies, in this case @pnp/sp did not do so.
However, we went through the effort of laying it out for you. Paste the following code in your config.json and @pnp/sp will now work.
To avoid having to paste all of these additional externals you can bring it up with the @pnp/sp folks.

"externals": { "@pnp/sp": { "path": "https://cdnjs.cloudflare.com/ajax/libs/pnp-sp/1.1.1/sp.es5.umd.min.js", "globalName": "@pnp/sp", "globalDependencies": [ "@pnp/logging", "@pnp/common", "@pnp/odata", "tslib" ] }, "@pnp/odata": { "path": "https://cdnjs.cloudflare.com/ajax/libs/pnp-odata/1.1.1/odata.es5.umd.min.js", "globalName": "@pnp/odata", "globalDependencies": [ "@pnp/common", "@pnp/logging", "tslib" ] }, "@pnp/common": { "path": "https://cdnjs.cloudflare.com/ajax/libs/pnp-common/1.1.1/common.es5.umd.min.js", "globalName": "@pnp/common", "globalDependencies": [ "@pnp/logging", "tslib", "adal-angular" ] }, "@pnp/logging": { "path": "https://cdnjs.cloudflare.com/ajax/libs/pnp-logging/1.1.1/logging.es5.umd.min.js", "globalName": "@pnp/logging" }, "tslib": { "path": "https://cdnjs.cloudflare.com/ajax/libs/tslib/1.9.3/tslib.min.js", "globalName": "tslib" }, "adal-angular": { "path": "https://secure.aadcdn.microsoftonline-p.com/lib/1.0.17/js/adal-angular.min.js", "globalName": "angular", "globalDependencies": [ "angular" ] }, "angular": { "path": "https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.7.2/angular.min.js", "globalName": "angular" } }

Feel free to reopen this issue if this did not work, I tested it with a vanilla webpart and it worked.

Thanks for the answer @dgaeta !
Question: why did you include AngularJS? adal-angular doesn't list it as any kind of dependencies. I know the naming is confusing as described here https://github.com/AzureAD/azure-activedirectory-library-for-js/issues/659

We can update our docs with this, didn't know about need to specify deps within the config like this. Thanks!

Hi,
It still does not work .
Something went wrong
If the problem persists, contact the site administrator and give them the information in Technical Details.
TECHNICAL DETAILS
Original error: *Resource "@pnp/odata" not found in loader configuration of manifest for component "a46f10ba-8670-4ac6-9aa9-347a3e53f88c" (CommonPnPWebPart).

INNERERROR:
*
Resource "@pnp/odata" not found in loader configuration of manifest for component "a46f10ba-8670-4ac6-9aa9-347a3e53f88c" (CommonPnPWebPart).
*
*CALLSTACK:
Error
at t [as constructor] (https://spoprod-a.akamaihd.net/files/sp-client-prod_2018-08-03.004/sp-webpart-workbench-assembly_en_651301445a8554d79a6bc383abe94a54.js:283:16003)
at new t (https://spoprod-a.akamaihd.net/files/sp-client-prod_2018-08-03.004/sp-webpart-workbench-assembly_en_651301445a8554d79a6bc383abe94a54.js:1068:20443)
at Function.e.buildErrorWithVerboseLog (https://spoprod-a.akamaihd.net/files/sp-client-prod_2018-08-03.004/sp-webpart-workbench-assembly_en_651301445a8554d79a6bc383abe94a54.js:1068:15140)
at Function.e.buildLoadComponentError (https://spoprod-a.akamaihd.net/files/sp-client-prod_2018-08-03.004/sp-webpart-workbench-assembly_en_651301445a8554d79a6bc383abe94a54.js:1068:11339)
at https://spoprod-a.akamaihd.net/files/sp-client-prod_2018-08-03.004/sp-webpart-workbench-assembly_en_651301445a8554d79a6bc383abe94a54.js:1068:67537

Getting the same issue on my end after testing.

We are working on a solution here. A couple of moving pieces and we want to avoid a hacky workaround.

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

Was this page helpful?
0 / 5 - 0 ratings