Extensibility Needs Examples

[nathanhammond]

This issue is for collecting examples of extending or subverting ember-cli EmberApp, commands, tasks, and models inside of the addon ecosystem. Please add one comment per example, as well as a brief note about what it appears to be trying to accomplish.

/cc @lukemelia @achambers @stefanpenner @kellyselden @runspired @trabus @Turbo87 @kategengler @chadhietala @trentmwillis @rwjblue

[stefanpenner]

Basically we are looking for some tasks/commands/addon mains that are too complicated or at least feel strange/redundant or painful

[runspired]

I've been collecting, lots coming, had to hunker down on client work this week but back at this project tomorrow late afternoon :)

[stefanpenner]

No rush, I'm also getting busy for the next few weeks. But if they are posted we can take a look as time permits and start formulating some solutions

[MiguelMadero]

I have a demo repo of how to create different "packages" as the output of a build. The important part is the ember-cli-build it keeps changing, so please look at this commit. There are more details on the README.

The goal is to break app.[js|css] into smaller packages or bundles based on a folder structure. This works great, but seems fiddly, error prone, it has some performance issues since some of the trees are still unnecessarily executing once per package instead of only once. It's also not super intuitive that we treat each "package" as its own EmberApp.

[nathanhammond]

From @tomdale

so addons can specify they need to run before or after a specific other addon but in my case, I need to have some trees be processed by broccoli-asset-rev, and some after specifically I have some HTML and JS assets that should be processed but then I need to write the final, rewritten paths of those to a manifest so basically: 1) I add some trees to the final app tree 2) those files get processed by broccoli-asset-rev 3) I add a new tree that contains a manifest I could manually invoke broccoli-asset-rev on my tree, but it seems bad…

Maybe he can provide a bit more color as to what's going on.

[stefanpenner]

@MiguelMadero can you move that to a gist please, or ideally a demo app using it, that would be great. I would like to prevent people from posting miles of code in this comment thread.

[MiguelMadero]

Done

[nathanhammond]

In our existing builder code if we want to run anything at the very, very, end of the build we can't do it without importing and monkeypatching the builder object inside of the host application, or redoing the build command from an addon, which requires unraveling an entire daisy chain of models and tasks and doing approximately what ember-cli-deploy has done.

This is one place where we'd like to insert arbitrary code: https://github.com/ember-cli/ember-cli/blob/master/lib/models/builder.js#L173

Basically, it's not possible to gracefully extend this behavior from within an addon.

/cc @trentmwillis @chadhietala @lukemelia

[chadhietala]

Difficult to coordinate and create layered artifacts. This is sort of the registry problem but with actually producing an artifact and not just transforming it. Example: You need to produce a config file. Addon A needs to write some metadata to this file. Addon B needs to write some metadata to this file. You can do i t today, but requires you create some global mutable state.

[chadhietala]

In development you should be running as close as possible to a production environment as possible. Currently serving the app is coupled to express. If you want to use something else there isn't a good hook or place to say please setup your server.

[rwjblue]

We are working on closing the ember-cli/rfcs repo in favor of using a single central RFC's repo for everything. This was laid out in https://emberjs.github.io/rfcs/0300-rfc-process-update.html.

Sorry for the troubles, but would you mind reviewing to see if this is still something we need, and if so migrating this over to emberjs/rfcs?