On JSPM and bundling choices

Framework Knowledge
1

Greetings.

Our application (which I inherited and assume was built on a skeleton, since it predates the CLI) uses JSPM for runtime package management, Gulp for handling transpilation/compilation (we use TypeScript@latest and target ES5) and aurelia-bundler (0.5.0 due to a problem with css) via a Gulp job for bundling. Since apparently Aurelia moved away from JSPM we are wondering if a more current alternative would be appropriate, especially moving forward to vNext.

Our use case is as such:

  • we need to bundle .js and .css only. No HTML nor images or other binary files. We could consider including the FontAwesome (Free) font files, which we currently keep in a separate not-bundled directory.

  • our application consists of multiple vendor bundles and multiple “own” bundles

  • we do not use any CDN.

  • we would greatly appreciate the ability to leverage the inheritance of @bindable on our components. It works in our development setup but it breaks upon bundling, I suppose because of that old incompatibility between Aurelia’s and TypeScript’s way of handling the metadata implementation.

  • despite bundling, we currently deploy the whole jspm_packages directory since 1. it contains the SystemJS files (which I guess could be moved elsewhere) and 2. we’d rather take up some space on our customers’ servers than have something not working beacuse of a forgotten non-bundled dependency.

  • as a far lower-priority note, we currently have IE11 compatibility as a requirement, but further down we could consider dropping it and targeting ES6+ (which would also mean smaller bundles due to not needing e.g. async/await transpilation). This does not seem to be possibile with our current toolchain.

From what I have gathered, the alternatives seem to be the CLI’s new bundler and Webpack. Considering our scenario and what is planned for vNext (which, due to its alpha state, we have never looked into yet):

  • would be worth it to replace JSPM?
  • which alternative would be more appropriate?
  • are there any detailed migration guides from JSPM to Webpack/the new Aurelia bundler?
  • (incidentally, is the aurelia-bundler package deprecated?)

Thanks in advance.

2

I think our new CLI bundler / loader is capable of handling your case. But I’m uncertain about it, so let’s ping @huochunpeng

About @bindable inheritance: as long as derived class has a single decorator for metadata on it, it will work fine, regardless bundler / loader / language.

For IE11 handling, there will need to be 2 output formats and either web server or index.html will need to be adjusted to support it.

3

Disregard my comment about bindable inheritance not working with bundling and working without; there must have been some other decorator on the classes I checked and it does depend on the presence of other decorators.
(As further reference for anyone stumbling upon this, autoinject does not seem to count as a valid “inheritance-triggering” decorator. customElement works as noted in the relevant GitHub thread.)

4

Migrating from jspm to cli bundler is easier than migrating to webpack. It definitely provides less maintenance overhead over jspm.

Give it a try. You should only need special config if you used shim (wrap legacy js lib into AMD module), but with cli bundler, using prepend is recommended over shim for simplicity.

The doc has a cookbook which covers font-awesome. All css files will be bundled, but not font files. cli provided “copyFiles” to help you to copy font-awesome fonts.

But if you want embedded font files (base64) in css, you can use postcss-url with postcss in gulp pipeline. I can provide additional snippet when you got there.