These are chat archives for systemjs/systemjs

23rd
Aug 2017
Aaron Godin
@aarongodin
Aug 23 2017 18:58
Hey all, are there any es6 module loaders that do not rely on a build step? I’m intrigued by SystemJS, but would prefer to keep everything as native modules.
Also, does anyone know if the proposal for async loading of es6 modules requires the modules to be in a format similar to System.register?
Or is System.register purely a systemjs thing
David Cole
@mrdavidjcole
Aug 23 2017 20:09
Hey! Dave from Wistia here. A customer of ours reached out because they're having trouble using SystemJS to load our player JS library, https://fast.wistia.com/assets/external/E-v1.js, with SystemJS.import('https://fast.wistia.com/assets/external/E-v1.js')
I was able to repro on this barebones example page: https://wistia-systemjs-testing.glitch.me/
the SystemJS.import call seems to choke on this require statement, var f = require('+i(d)+') which works fine when our library is loaded any other way (like, the problem doesn't occur if you load with via a script tag)
for some reason, when it sees that require statement, it tries to load the contents of it like it's a relative URL, and errors on (in that example) https://wistia-systemjs-testing.glitch.me/+i(d)+
anyone seen that sort of thing before? Seem like a bug in SystemJS perhaps?
David Cole
@mrdavidjcole
Aug 23 2017 20:15
Randall Leeds
@tilgovi
Aug 23 2017 23:20
@aarongodin all loaders have to parse the modules for imports, even native browser loaders. Without native support, a loader implemented in JS has to either parse it at runtime or have a build step. Native loading of ES6 modules does not require the SystemJS format, but I think the SystemJS format is designed to work with it. In other words, the native loader might get an API for programmatic injection of modules. The SystemJS format works against that API. Without a build step, the loader parses and calls these APIs internally, itself. You can use SystemJS without a build step, but then you are "building" just-in-time.
And here's an example of just-in-time parsing/building: https://github.com/ModuleLoader/browser-es-module-loader
SystemJS exposes an API that the built-in loaders might one day support. The SystemJS module format is an ES6 module transformed to call the API directly rather than having the loader parse the ES6 and instantiate the modules itself.
My language might be imprecise, since I'm not as much an expert on this as the folks directly working on these loaders and specs, but that's my understanding.
Think of SystemJS as a loader with its guts exposed so you can directly instantiate modules into its module cache. The SystemJS module format is just a module that has its imports/exports parsed and replaced with calls to those gut-manipulating APIs, so that the loader doesn't have to parse it and discover the imports/exports at runtime.