Bundling and "externals"


My current project uses jQuery and sp-pnp-js, and I have moved these to a document library in a "cdn" site collection in my tenant (it's not a *real* CDN, I just call it that -- it really is just a document library).  This has worked pretty well so far:

"externals": {
    "jquery": "",
    "sp-pnp-js": ""

My question is related to something I see in a lot of blog posts on the topic - many times I see examples (hello, @Waldek Mastykarz) where the following is also in the externals section of config.json, like so:

  "externals": {
    "@microsoft/sp-client-base": "node_modules/@microsoft/sp-client-base/dist/sp-client-base.js",
    "@microsoft/sp-client-preview": "node_modules/@microsoft/sp-client-preview/dist/sp-client-preview.js",
    "@microsoft/sp-lodash-subset": "node_modules/@microsoft/sp-lodash-subset/dist/sp-lodash-subset.js",
    "office-ui-fabric-react": "node_modules/office-ui-fabric-react/dist/office-ui-fabric-react.js",
    "react": "node_modules/react/dist/react.min.js",
    "react-dom": "node_modules/react-dom/dist/react-dom.min.js",
    "react-dom/server": "node_modules/react-dom/dist/react-dom-server.min.js"

Should I be doing this as well? Also, this doesn't really make sense to me; if these files are in a sub-folder of the project itself, how are they "external"? I'd love to know what's actually going on here and whether it is something I need to be aware of for my own solutions.  Thanks.

10 Replies

Sorry, I don't know the answer to your specific question, but you may be interested in using a real CDN that MS recently announced support for, see for the details

@Dean Gross,


Thanks, yeah, I've played with that and got it to work fine.  But given the fine details (limited support for Private CDN, and Public CDN being...well, *public*), that solution is a non-starter for my customer -- they're much more comfortable with their assets continuing to be contained directly within their own SP sites. A dedicated site collection, site and document libraries are serving that function well at the moment.  If the customer comes back to me at a later date worried about performance, I can have the CDN talk with them again.


My question is not about where the assets should be stored -- it's about which ones I should instruct the tool chain to treat as external to the project so I don't end up bundling the same code into multiple web parts which will be running on the same page.  I'd like to lighten the web parts as much as possible to improve page-load performance on the intranet.

"Public" is a poorly choosen word, all that it means is that anyone who has access to the tenant will have access to the resource. If you are not already logged into the tenant then you cannot get to the item in the "public CDN". @Vesa Juvonen explained this in his demo.
best response confirmed by Joseph Ackerman (Contributor)

You don't need to do this. What you're looking at is a project created an older version of the SharePoint Framework, where more packages have been listed as external. In the latest version it's not required anymore which is why you're not seeing them anymore.

Thanks, Waldek.  I thought it might be something like that :)


This is the problem with not having FULL/COMPLETE/THOROUGH/CURRENT documentation for the platform.  When we have to rely on trawling the web for posts to get info, it's inevitable that some will be out of date because what's on the internet is pretty much there forever...


Thanks again.

@Dean Gross,

Interesting that you would say that because that's not what I remember from his demo, and a subsequent Webinar on JS security from Rencore a few weeks ago made a point of saying that using a CDN was a trade-off to get better performance at the expense of the asset's security.


Can you point me to the "spot" in the video where Vesa says this?  Thanks.


I don't know about the exact bit you're referring to, but what Vesa said, makes sense if you're thinking about using a public CDN. Imagine: you're loading a script from a location that you have no control over. If that script gets hacked, and given that it's running without any restrictions on your intranet pages, it could be used to gain access to your confidential data. This risk is not specific to CDNs: any location that's not properly secured and doesn't have its governance in place poses the same risks.


It's worth keeping in mind that using a CDN doesn't guarantee a better performance. If your organization has one office or is located in one region, you could get better performance from a hosting location optimized for serving static assets than from a CDN. CDN offers you the most benefits, when your users are spread all over the world.

The latest documentation is available at It consists of guidance articles and tutorials describing specific scenarios. It's all GitHub-based so if you see any mistakes, inconsistencies or are missing specific documentation, please don't hesitate to submit an issue on GitHub at The documentation is open source, so you can request a specific article as well as write it yourself and submit as a pull request.

@Dean Gross@Waldek Mastykarz,


Thanks, guys.  Very helpful information.  Should help clarify things for the client! :)