Ember CLI in 2018

Hey all!

Ember CLI core team would love to get your feedback on the 2018 roadmap: features, improvements, pain points, and anything that would improve your DX.

Here’s what we are planning to discuss during EmberConf:

  • Tree-shaking/Code Splitting/Dynamic Imports/out-of the-box npm support (already underway)
  • Yarn Workspace support
  • Improved documentation (potentially merge with Emberjs website)
  • Drop support for Node 4
  • Remove broccoli-builder fork (this will let us take advantage of the system $TMPDIR and remove tmp folder)
  • Deliver Module Unification
  • Make errors more ergonomic (potentially introduce error index).
  • Web/Service Worker Support
  • Better PWA support

Updates based on the feedback:

  • Working sourcemaps (for small and large apps)
  • Reducing build & reload times/easier debugging of slow build times (identify and reason about slow build steps; the ability to identify add-ons that don’t cache properly)
  • Improved documentation:
    • how to write fast addons, use Broccoli, and on all the hooks
    • best practices
    • naming conventions (e.g. does ember-cli-* and ember-* actually mean anything?)
    • better blueprints (e.g. index.js could include all available hooks as blank functions)
  • Plan forward for Ember Fastboot
  • Plan forward for Ember Engines (difficult to understand; lazy loading should be much easier to setup)
  • Plans for supporting the upcoming Babel 7
  • Direct native npm imports
  • Import Ember microlibs in Node.js

Link to assembled discussion bullet points

We are looking forward to your feedback. If you have any questions, do reach out to us in Slack channel: -ember-cli


That stuff all sounds great :slight_smile:

I think another area that would have a huge impact on our daily lives while working on ember apps is reducing the build time.


I’m glad better docs are on there. I would particularly like to see docs on how to write fast addons, use Broccoli, and on all the hooks.


I’m excited to see a lot of these ship. Some things that come to mind:

  • Easier debugging of slow build times. For instance, making it easier to identify and reason about slow build steps or the ability to identify addons that don’t cache properly.
  • JS Sourcemaps improvements for large apps. They are currently extremely slow and pretty much unusable.
  • Ember Engines (although probably not strictly an Ember CLI team concern)
  • Also any plans for supporting the upcoming Babel 7

Absolutely rebuild+reload times. Especially on bigger apps, waiting on each save, tens/hundreds of times a day, is a major waste of developer time and focus.

1 Like

I think all of that sounds amazing. Ya’ll are the best.

1 Like

This sounds good. Perhaps settle on some deploy default so ember-cli can optimize more based on what we are deploying. The deploy can than split vendor.js in a browser tread and Web/Service Worker treads to get even more speed.

It’s pretty frequent for me to see huge variability in my first build times. Sometimes the time jumps from ~20s to around 60-70s. Sometimes that’s right after updating addons, but often it occurs from just a restart of ember serve.

In almost all cases, the time goes back down to the normal range just by blowing away tmp and dist and restarting ember serve.

It would be a huge quality-of-life improvement if I never had to deal with the rebuild process inexplicably taking way longer than a fresh build.

Otherwise the list of priorities sounds great! Keep up the good work. :clap:


From my experience, I see ember-cli is extremely slow on windows, while the same app builds very fast on *nix (including mac) environments.

We did follow the instructions for ember-cli-windows and the issue persists still. Another thing we notice is the “so-called” anti-virus kicks in every time we build ember apps.

Working in a corporate environment where we do not have any* say on the exclusions, we have no choice but to wait for AV to complete it scanning (which takes around 10 - 15 minutes or more at times).

And these build times are the major roadblock to increasing ember utilization in a corporate world.

Any possibility of having anti-virus not to be too much suspicious on ember-cli would be of great help.


I have some thoughts on ember data documentation https://gist.github.com/oligriffiths/cff30253e2c2d7534494e6f11679fc7d

I’d also like to see support for pagination of relationships in ED, a sorely missed feature.

1 Like

Ember engines are incredibly difficult to understand or at least time I read them they were so complex. I feel like lazy loading should be much easier than having to do all of this setup.

FWIW, I believe the goal here is to specifically gather work items for ember-cli itself…

Currently environment.js, targets.js, coverage.js, deprecation-workflow.js, dotenv.js all reside in the config folder. Would love to see ember-cli-build.js moved to the config folder as well. It will suite well there perhaps with a simpler file name like build.js.

1 Like

Awesome. Some ideas off the top of my head

  • Better docs :100:
    • integration with Ember website
    • updated (or at least timestamped / version labeled) API docs
    • best practices
    • naming conventions (e.g. does ember-cli-* and ember-* actually mean anything?). Write it down so we at least know which addons are doing it wrong.
    • better blueprints (e.g. index.js could include all available hooks as blank functions)

Other than that, I don’t have any complaints or requirements from Ember CLI :slight_smile: good work to everyone involved!

These suggestions are coming from having written my first addon recently and having to end up reading the source code to understand what was going on.

  • Faster Build times, ambitious but amazing goal would be to make it 10x faster.

  • Drop ember ES6 shimming, direct native npm imports.

  • ember microlibs importable in node.js. People should be able to require or import EmberObject or Ember.Route or Ember.Component and play with it/debug it interactively in node or use them in their npm packages(particularly Ember.Object/computed properties could be very useful in backend ORMs).

  • ember fastboot should be actively maintained with more focus on its development and advertising.

If we can get these things we will win the javascript space. I still believe that. This comes from someone who avoided Ember back in the days, I love ember since 2.0.

1 Like

We should spin up a separate thread about this specifically. This is largely already possible, but likely poorly documented and probably has rough edges we should discuss…

Module Unification :+1:


done: Ember microlibs & npm importability

I am dumb sad face

1 Like

Module unification would be the most important feature for us. We have about a thousand files now. Our current, unsatisfying workaround is to group the files using in-repo addons.

1 Like