#EmberJS2018
There has been lots of talk about tree shaking, code splitting, and native node module imports in the #EmberJS2018 blogs. My goal is to better inform everyone of how that is going.
The package hook: The concept of a packager has been around for years, but it is https://github.com/twokul that is finally bringing it over the finish line. It is very close to being done. The bulk of the code is merged into Ember CLI behind a feature flag. The hook will look something like this:
let app = new EmberApp(defaults, {
// Add options here
});app.package = function _package(tree) {
// do things to `tree`
return tree;
};return app.toTree();
His next step is to move all that code to https://github.com/ember-cli/ember-cli-default-packager. Then the feature flag can be removed for everyone to use (and abuse).
Since the bulk of the work on the package hook is done, this opens the door for custom packagers to start development. The one I’ve been working on is https://github.com/kellyselden/ember-cli-rollup-packager. I think the API will look something link this:
const rollupPackager = require(‘ember-cli-rollup-packager’);let app = new EmberApp(defaults, {
// Add options here
});app.package = rollupPackager({
// options
});return app.toTree();
This Rollup packager is currently being ported from https://github.com/kellyselden/ember-cli/tree/rollup, where limited tree shaking and native node module imports are working. What is limited tree shaking you might ask? The easiest thing for me to tackle first was JavaScript imports only. This means that if some Ember addon JavaScript code is not used by your app, it is eliminated from the bundle. The next steps for tree shaking are considerably harder. How do you know if an Ember service is unused? Since there are no JavaScript imports, only Ember’s dependency injection, it gets tricky for Rollup to follow these dependencies. Similarly for Ember components and helpers, there are no JavaScript imports, only template lookups. Once the first version of the Rollup packager is finished, these are next on the agenda.
I had to make lots of changes to Rollup to support the Ember ecosystem, which have been merged into the Rollup project. I feel like I’m a Rollup core member now with how much I know about Rollup’s internal code ;) I’m at the tail end of the port from my Ember CLI branch, and as of May 31, the Rollup packager is working™. Very soon, using the master branch of Ember CLI and some environment variables passed in, you will be able to use the experimental Rollup packager.
As for code splitting, to be honest I haven’t thought that through much yet. The most common case we will want to support is per-route splitting. Unlike tree shaking, code splitting will probably involve changes to Ember for an app to be able to operate in pieces, much like Ember Engines (In fact, one of the stretch goals in all of this work is to reimplement Ember Engines using the new packager API and a custom packager, although that’s a topic for another day). @twokul has many more thoughts about the code splitting problem than I do.
My plan is for this Rollup packager is to become the standard packager for Ember CLI, pending RFC approval of course, but that shouldn’t stop others from experimenting with other bundlers. There’s no reason why their couldn’t be a webpack or a parcel packager, although I expect they will need a similar amount of changes to support the Ember ecosystem.
That’s my status update on what I’ve (we’ve) been working on for months now. I had hoped to have it ready for EmberConf, but alas things…
