The spec for the standard JS module loader has recently been changing. The JSPM and SystemJS teams have been working hard to align with the new specs. And as of this release, Aurelia is now aligned with the new JSPM and SystemJS Beta.
Tag Archives: JSPM
This is an early stage project under active development. If you find a bug, please raise an issue!.
Right now, you have a few different options if you want to create a bundle out of your ES6 modules:
- The best option, in terms of performance, size of the resulting bundle, and accurate representation of ES6 module semantics, is to use esperanto. It’s used by ractive.js, moment.js, Facebook’s immutable.js, the jQuery Foundation’s pointer events polyfill, Ember CLI and a bunch of other libraries and apps
- You could use jspm, which combines a module bundler with a loader and a package manager
- Or you could use browserify or webpack, transpiling your modules into CommonJS along the way
In Part I of this series, we configured webpack for building backend apps. With a few simple tweaks, like leaving all dependencies from
node_modulesalone, we can leverage webpack’s powerful infrastructure for backend modules and reuse the same system for the frontend. It’s a relief to not maintain two separate build systems.
This series is targeted towards people already using webpack for the frontend. You may find babel’s require hook fine for the backend, which is great. You might want to run files through multiple loaders, however, or share code between frontend and backend. Most importantly, you want to use hot module replacement. This is an experiment to reuse webpack for all of that.
In this post we are going to look at more fine-grained control over webpack, and how to manage both frontend and backend code at the same time. We are going to use gulp to drive webpack. This should be a usable setup for a real app.
Some of the responses to Part I criticized webpack as too complicated and not standards-compliant, and we should be moving to jspm and SystemJS. SystemJS is a runtime module loaded based on the ES6 specification. The people behind jspm are doing fantastic work, but all I can say is that they don’t have many features that webpack users love. A simple example is hot module replacement. I’m sure in the years to come something like webpack will emerge based on the loader specification, and I’ll gladly switch to it.
The most important thing is that we start writing ES6 modules. This affects the community a whole lot more than loaders, and luckily it’s very simple to do with webpack. You need to use a compiler like Babel that supports modules, which you really want to do anyway to get all the good ES6 features. These compilers will turn ES6 modules into
require statements, which can be processed with webpack.
I converted the backend-with-webpack repo to use the Babel loader and ES6 modules in the
part1-es6 branch, and I will continue to use ES6 modules from here on.
Couple weeks ago I have started to work on one of my personal projects (Employee Scheduling) and at that time I didn’t think I will write any of my code in ES6 not because I wouldn’t want to try one of the cool ES6 features but I was more concerned how to automating my development workflow with ES6 and I also want to get my code to production until I watched Guy Bedford video from JSConf2014 where he was talking about ES6 modules workflow using JSPM. As you may guess JSPM solves a lot of my concerns and today I want to share my ES6 development and production workflow using JSPM. The Employee Scheduling application screenshot: