JSPM SystemJS Support

[RobLoach]

http://jspm.io

[balupton]

so many package managers

[RobLoach]

:package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package::package:

[balupton]

@RobLoach do you use this? @hypercubed I think you do right? Is it a big thing? many people use it? what's the advantage of it over the 2013+ browserify/webpack workflow?

[Hypercubed]

Yes, and I love it. Before I rant about it I should admit that I have never used webpack... I have used Browserify, babel, and a few other ES6 bundlers for developing individual modules, but JSPM/SystemJS is my choice for web applications.

1) JSPM is a package manager, similar to NPM or bower. The advantage here is that it can install from both NPM and, like bower, directly from github. You can install modules that were intended for just the browser and modules meant for node. It installs the packages in a way to avoid version collisions and generates a config file for SystemJS... maybe equivalent to requirejs config file. I'm not sure where this is in the Browserify/webpack workflow.

2) SystemJS is an extension of the ES6 module loader spec polyfill. It uses traceur (or babel) to transpile ES6 to ES5 in the browser (at least during development). SystemJS is ES6 focused while Browserify is CJS focused. Ideally the need for this polyfill will disappear in the future. SystemJS and Babel/Traceur should get more and more superfluous as time goes on.

3) JSPM SystemJS builder, which I think is the closest to a Browserify/webpack workflow, inspects the application structure, navigating down through imports/exports to generate a bundle of the web application before deployment. In a sense I think this is also going to be less useful in time with HTTP/2.

So I guess JSPM/SystemJS, while in some ways seems much more of a hack than Browserify, allows us to write specifications compliant future Javascript today that gets less hacked together with time.

Edit: added some links

[balupton]

@Hypercubed if I wanted to start making our packages available to jspm, do I need to publish them to npm and jspm?

[Hypercubed]

Nope, JSPM has a registry but that is basically "package_overrides" for when JSPM can't figure out what is going on from the package.json. The overrides can be included in the package.json under the JSPM key.

For example today I was using jspm install npm:esnextguardian to test esnextguardian. jspm install esnextguardian=github:bevry/esnextguardian works as well.

(I should probably say in this case there is likely never a reason to need to install esnextguardian using JSPM)

[balupton]

there were some interesting discussions over at https://github.com/bevry/domain-browser/pull/7#issuecomment-171592957 about this

[balupton]

I'm inclined to recommend SystemJS over ender, browserify, and wzrd.in

[balupton]

Would be cool if SystemJS supported https://github.com/bevry/editions

in having https://github.com/systemjs/systemjs/blob/master/docs/module-formats.md align with https://github.com/bevry/editions/wiki/Syntaxes

examples of editions https://github.com/bevry/editions/wiki/Examples

tweet thread - https://twitter.com/balupton/status/834281841196556288

[balupton]

Reposting https://github.com/bevry/base/issues/19#issuecomment-440924633

---

Closing.

This is an issue for https://github.com/bevry/boundation

Regardless of that hoever, jspm (and all the other builders) should really add support for https://github.com/bevry/editions rather than everything having to add support for their specific thing (e.g. browser field, jspm field, module field, etc etc etc).