Ember CLI in 2018

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

Looks great!

  • Consider if some dependencies can be hidden from package.json

Fewer packages make it easier to upgrade, less overwhelming for new users. For instance, can the packages ember-resolver, ember-load-initializers, ember-cli-htmlbars be hidden under the ember-cli package somehow?


Great roadmap! :trophy:

For the product I work on, the number one item on our wishlist is:

  • Deliver Module Unification

The other items are also good stuff, but they are secondary to module unification (we have a fairly large app, 115 components, 136 routes, etc so the current structure is starting to break down). Module unification would be very helpful for us!

Regarding the website, I think merging with emberjs.com would be good. Especially for newcomers! If needed, it could still be a separate ‘build’ (similar to how the API and Statusboard are separate pieces).

Single file component!

Single file components is largely an Ember feature (which is already possible technically)…

Totally agree with this. Our organisation almost gave up entirely on ember due to the issues in trying to get ED working with .net backend. Fortunately we switched yo using AJAX requests and we didnt throw out the baby with the bath water but the documentation should introduce ED far later and not thrust on us by default.

Module Unification!!!

I would also love if the Ember CLI docs were in the main Ember site as well.

1 Like

Don’t you need Ember CLI to split the single file and compile each part individually?

Making the ember builds independent of the build tools. Ember CLI can expose a build API which build tools can use. Officially Broccoli integration for the build API will be supported by the CLI team but the wider community can come up their own solutions with today’s hotness such as Webpack. Packaging Strategy RFC proposes to support this feature partially but would love see ember builds become completely independent. This will open up a new area of experimentation around ember builds.

1 Like
  1. Module unification
  2. Better build times
  3. Tree shaking
  4. PWA

All the other ideas are also good but this list is what matters the most to me

I would offer a mode that relies on browser ES6 support and skip the build altogether (read this). It’s a dream I’ve had for a long time and that I recently started to implement (not in Ember though). I really love the simplicity it brings.

Development mode As developers, we use the latest technology browsers. We can already use most of ES6 in Chrome. Why would we need compilation altogether? If we remove compilation, no build time. We start the server and we are good to go. Oh and we wouldn’t need sourcemaps anymore. The only exception would be css processors and templates.

Compiled mode We still need compilation for browser support. A production mode would let us run the compiled code. It might even be the mode we would run if Ember moves toward TS like Glimmer did.

I totally agree on that point. Sometimes I write ember-cli addons and it’s always a “pain”. I’m never quite sure if my solution is “good” or not… Also, tips and tricks for developing ember-cli addons would be nice. For example, I read on some blogpost how to use node --inspect-brk in conjuntion with developing ember-cli addons.

A good (maybe visual) explanation of Broccoli and it’s trees could be also helpful.

These points are the main points why I had to write ember-cli addons. Most of the time my custom addons are here for creating separate bundles, creating inline-css, inline-scripts and things like that.

Speaking of bundles, I think it would be great to create at least two different bundles. One for modern browsers with full ES6/ES2018 (or however you want to call it) support and one bundle for legacy browsers which is compiled back to ES5. This way we could use modern features (like async/await) without degrading the performance for all users.

And there is one huge pain point. Hot reload of CSS with ember-cli-sass just doesn’t work on my machines anymore. If you want to restyle something you always have to go through the whole build process and in worst case have to click through the UI to create a certain state. This is even more annoying if you try to solve some CSS bug and you are not 100% sure how to do that. Of course, you can use the dev-tools but sometimes it’s quite involved (sass variables etc) and it would be nice if you wouldn’t have recopy all the stuff from the dev-tools to your code.

But overall ember-cli is an awesome project! Thanks for all your work and passion.

  1. Better build time for sure
  2. Decouple broccoli so we can use something else - webpack? something else?