Sp-dev-docs: Request for a proper SharePoint JavaScript CDN

[wictorwilen]

Category

• [ ] Question
• [ ] Typo
• [ ] Bug
• [X] Enhancement / Suggestion
• [ ] Additional article idea

Expected or Desired Behavior

Currently when we want to use the legacy SharePoint scripts, including JSOM we need to add a few external scripts to the config.json file, shown in Wikis and other issues such as #432. The problem with this approach is that you _hard code_ a tenant name in you app package, which means that you can not reuse the solution. An alternate approach would be to use the static.sharepointonline.com CDN like this:
json "sp-init": { "path": "https://static.sharepointonline.com/bld/_layouts/15/16.0.6309.1208/init.js", "globalName": "$_global_init" },
However this does not work as intended, as it is a version number hard coded in that URL and older versions of those scripts are not kept in the CDN, so eventually the solution will break.

I suggest that either:

• static.sharepointonline.com keeps older versions of the JavaScripts
• there is a _latest_ option at static.sharepointonline.com, like this https://static.sharepointonline.com/latest/_layouts/15/init.js

Thoughts?

[waldekmastykarz]

The challenge with using _latest_ I see would be that it would be a moving target: your web part might work one day and stop working the other without you having any way to control it.

I'd vote for the first option with preserving older versions of scripts. If the versions are guaranteed to be backwards compatible then including the first two or three numbers like https://static.sharepointonline.com/16.0.6309/_layouts/15/init.js or https://static.sharepointonline.com/16.0/_layouts/15/init.js would be sufficient.

[wictorwilen]

Absolutely agree. Latest is not optimal at all, but if we only can keep one version the latest is better than the oldest :-)

[andrewconnell]

@waldekmastykarz 's solution is similar to how the Office JS guys do it for Office Addins. If you reference /1/ you always get the most current v1 instance. Otherwise the more specific the version you use in the URL, the more specific version you get:

For instance, these will all return the same file assuming the current version is 16.0.6309

• 16
• 16.0
• 16.0.6309

Maybe an easier to read format would be: 16.*.*

However, this does bring up an important question: are SP JS files following semver? If not, this model isn't any more reliable than always grabbing latest.

[navarrorc]

Any update on this? I have been using the following path for a while now
https://static.sharepointonline.com/bld/_layouts/15/16.0.6802.1208/init.js
Can I expect this to continue to work indefinitely?

[patmill]

Have you considered simply writing code like this:
"sp-init": { "path": "/_layouts/15/init.js", "globalName": "$_global_init" },

That will give you the latest version from the current tenant, but you don't need to hard code the path

[wictorwilen]

@patmill - doesn't work for me (with version 1.4.0). When running package-solution I get the following error:

[17:18:09] Verifying configuration... [17:18:09] Error - Error: The webparts manifests list is empty. Please ensure you have done a build and that your config file is pointed at the correct folder. [17:18:09] Error - Error: The webparts manifests list is empty. Please ensure you have done a build and that your config file is pointed at the correct folder. at Object.createPackage [as default] (C:\code\XXX\XXX\XXX\node_modules\@microsoft\sp-build-core-tasks\lib\packageSolution\packageSolution\createPackage.js:25:19) at DestroyableTransform.gulp.src.pipe.through2.obj [as _flush] (C:\code\XXX\XXX\XXX\node_modules\@microsoft\sp-build-core-tasks\lib\packageSolution\PackageSolutionTask.js:112:36) at DestroyableTransform.<anonymous> (C:\code\XXX\XXX\XXX\node_modules\through2\node_modules\readable-stream\lib\_stream_transform.js:138:49) at DestroyableTransform.g (events.js:292:16)