I want to point out at the get go that there are 2 major areas we can optimize. I've given this some thought and have some new ideas. Sorry that this has taken so long, I took a break and have been focusing on However, this means that to load a package, there would be at least 3 requests: 1 to get the package.json, one to get the root directory listing and at least one more to load the pre-built file.
Having a per-package configuration would be unviable because of the sheer quantity of NPM packages and the pace of updates, so the only other way would be to implement a custom SystemJS resolver for unpkg that would get a directory listing as well as the package.json to identify where to pull the pre-built files from. The main problem with NPM packages is that they're all implemented using a variety of precompilers (babel, traceur, tsc, etc) and when they ship with pre-built "true" JavaScript files (ie that would run as-is in the browser) these files can be placed and laid-out in many different ways.įor instance, is not usable as-is as the requires wont' resolve ( require("./gl-matrix/common.js") points to The other problem is that the JS files likely won't work as-is in the browser, and we should instead use the pre-built version in The does not specify a browser: entry either, so how would the SystemJS unpkg config manage to locate and load the prebuild file in that case? From on Decem I was wondering how you would manage the various pre-built JavaScript configurations we find on NPM projects.
0 kommentar(er)
