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?
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).
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.
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.
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.
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.
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.
One thing that I haven’t seen mentioned here, but actually seems to crop up quite a bit in the form of confusion when chatting with folks is the fact that ember-cli itself does not have an LTS policy. Commonly, folks that are trying to stick with a given Ember LTS version will stay on that “version paired” ember-cli version as well, however this means they are missing loads of bugfixes, Node version support, etc.
I’d like to discuss adopting Ember’s LTS policy for ember-cli…