Ember CLI, 2018 Edition

The Ember CLI team spent the day after EmberConf talking about our priorities for the upcoming year. We meet annually, and this time around we decided to publish the notes from our meeting to make sure our direction is transparent for everyone in the community.

We asked the Ember community beforehand for feedback on the issues and pain points with Ember CLI. We do want to thank everyone who participated. Your feedback is very valuable!

Here’s a summarized list of the most anticipated features, based on your feedback:

  • Module Unification
  • Tree-shaking and code splitting
  • Better PWA support (service workers)
  • Build times (both first and subsequent)
  • Broccoli and Ember CLI documentation
  • The future of Ember Engines and Ember Fastboot

Along with the above, we also wanted to discuss:

Module Unification

Matthew Beale, aka mixonic, joined us this year to discuss the remaining work needed for Module Unification to land. He also created a quest issue, which makes it easier to track progress and seek help as it is a no small task. We will refer to Module Unification as MU for brevity reasons.

To ensure a graceful transition to MU, we will support three compatibility scenarios:

  • MU application uses MU addon
  • MU application uses an addon with a classic layout
  • An application with a classic layout uses MU addon

These come with a list of changes:

  • The main property in package.json will point to src/index.js to make the Node module resolution algorithm work correctly for Ember addons from now on. This ensures that an import such as import Resolver from 'ember-resolver'; will properly resolve to the addons src/index.js via normal node resolution mechanisms. We can then use awesome editor plugins for auto-completion, eslint plugins for validation, etc.
  • The addonMain property in package.json will point to the add-on build file (index.js until now)
  • Addons will have classic and MU “dummy” application to run tests against
  • Addons will be able to customize MU config
  • Addons will be able to specify re-exports from MU add-on to classic application

Treeshaking and Code Splitting

Webpack and Rollup have become very popular nowadays, and they provide the forementioned functionality out of the box. However, they both are assets bundlers whereas Ember CLI has an opinionated build pipeline, and bundling of assets is just one of the steps.

Packager RFC introduces a single customizable method that receives all the content and is responsible for emitting the final dist/. The implementation is in progress and once it is finished, we can move to a more direct experimentation phase, and implement several “packagers” using Webpack and Rollup. These packagers would be able to treeshake your code and dependencies and allow imports of ES6 modules to “just work.” CJS imports will be a little more tricky as it is not as straightforward to implement. In the meantime, there has been work to bridge this gap in functionality. ember-cli-cjs-transform has been updated to use Rollup itself, meaning it will take in all the files it needs with one app.import(). It also incidentally works with ES6 module projects as well.

Kelly Selden has been experimenting with treeshaking and submitted several pull requests to Rollup (rollup/rollup#1986 and rollup/rollup#2089) to support the needs of Ember.js applications.

Service Workers Support

Service Workers are proxies between your web application and the network (if it is available).

Adding a service worker to your web application can help with overall performance, but it’s rather easy to make a mistake while using it. The Service Worker adds a complex cache layer. We want to make sure that Ember CLI users have the right tools at hand to be able to test and verify the intended behaviour. For example:

  • Ensure that a service worker is wired to the right project
  • Ensure that a service worker is invalidated for every build
  • Ensure that index.html key is invalidated per build
  • Ensure that a service worker caching works nicely with Fastboot caching of index.html
  • Ensure fingerprinting order is correct
  • Ability to unregister a service worker (for example, ember-macro-benchmark)

In addition to the list above, there needs to be a solid testing story for both consumers and Ember CLI add-ons, as well as proper documentation.

We invited Marten Schilstra to join us to discuss his opened RFC proposing to add a service worker to the default application blueprint, which would support offline caching index.html, JavaScript/CSS assets, and will be scoped to rootURL configuration. Nothing has been decided yet, but we’re looking forward to your feedback on the RFC.

Broccoli, Butter, and Cheese

Broccoli.js - the asset pipeline tool that Ember CLI uses to build Ember.js applications - has served us very well over the years. However, the lack of documentation about how it works and how Ember CLI uses it is painful for the Ember.js community. For instance, not many people know that Ember CLI uses a fork of Broccoli.js for historical reasons. We want to fix that this year. A high-level plan:

  • Unfork Broccoli.js and integrate Ember CLI with the latest version
  • Update the website and documentation
    • Define API surface better
    • List core plugins: User broccoli plugins, default set (rm, map, filter, reduce, etc.)
    • Make it easy for other people to contribute documentation
  • Improve error messages and error reporting middleware
  • Improve build performance (FS symlinks with virtual in-memory links, avoid re-building plugins whose inputs haven’t changed, etc)
  • Ability to use OS temporary directory (as opposed to tmp directory in the project)

Ember Fastboot

Fastboot is the server side rendering solution for Ember applications. It released its v1.0 in mid-2017. Since then the developer experience has got better. Recently, Jonathan Jackson landed rehydration of server side rendered Ember apps in FastBoot. It is behind an experimental flag and Ember applications need to turn on the flag in order to use it with Fastboot. A high level plan of Ember Fastboot includes:

  • Getting rehydration to land on stable branch
  • Improve documentation of Ember Fastboot with more real world examples of best practices and usage
  • Improve the error handling in rendering of Ember apps on server side during development
  • Better testing APIs for apps using Ember Fastboot with actually testing the server side rendered content as well.
  • Better support of developing Ember apps with Fastboot and mirage
  • Improved integration with Ember data and Fetch.


Following the example of Ember.js, Ember CLI will adopt an LTS release process. It will coincide with Ember.js LTS releases.

LTS releases give the community a set schedule that works for users who prefer a slower pace without hurting active iteration on features: on canary, you get features as quickly as they land, but get no guarantees about those features; on the stable release channel, you have to wait up to 12 weeks for features to stabilize and make their way through the beta process, but you are rewarded with semver guarantees.

LTS releases will provide a list of deprecation warnings to make upgrades to the next version easier. To avoid a possible “wall of deprecations,” we will also offer a way to silence them and fix at your own pace (similar to what ember-cli-deprecation-workflow does.)

The first LTS release will be announced in a separate blog post with all notable changes.

Node.js 4 Support

Ember CLI will drop support for Node.js 4 after the end-of-life date which is April 30th, 2018. A separate quest issue will be opened.

Ember CLI Update

Updating Ember CLI can be a tedious process, especially if one doesn’t do it often. Kelly Selden wrote a tool that automates upgrades and relies on git to do so: run ember update or ember-cli-update and that’s all.

It has been out for some time now and we think it is time to make it an official update tool for Ember.js applications and addons moving forward. Check it out here.

Ember CLI Team

Working on open source projects is a ton of work, and we would like to thank Nathan Hammond, Chad Hietala, and Jake Bixby for their commitment as they are retiring from the Ember CLI subteam. They retain all the rights but will be transitioned into “emeritus” status.

We would like to welcome Alex Navasardyan to the Ember CLI team, who has already done a lot of work in the Ember CLI space and is now finally an official member of the team.

Last but not least, we wanted to thank CrowdCompass and Mark Avery for hosting the Ember CLI team meeting (and for very yummy donuts) on short notice.


Awesome, thank you!

Definitely looking forward to discussing any parts that folks are interested in digging deeper into…

@twokul And what was decided about the future of Ember Engines? Only note about Fastboot.

Engines aren’t going away. Internals are going to be re-written (once packager lands). I’m not sure what’s going to happen with official documentation (likely be merged into main website), I’d ask @locks about that.

1 Like

@twokul one last question…ember-engines will it continue as a plug-in design apart, as well as ember-data? or will it be incorporated into ember-cli?

As discussed in this post Readers' Questions - "What is the status of ember-engines?", the ember-engines addon is really two main things:

  1. The build time code needed to enable “lazy engines”
  2. The runtime code needed to enable the encapsulation provided by the framework

It is our general plan that the custom build time code that enables “lazy engines” will be moved out of the ember-engines addon and instead be a baked in concept of the ember-cli packaging step. This should not mean conceptual changes for engine authors or users, it should however remove a very large amount of brittle highly coupled code that consistently causes issues for folks. :smiley_cat:


Great @rwjblue

Thank you for clarifying