Addon discovery and isolation

[lukemelia]

The goal of this PR is to address #2714 by moving to a model where addons are more isolated, and addons that have addons don't pollute the project with the dependent addons.

Feedback welcome.

• extract discovery of addons from Project to it's own AddonDiscovery object
• extract initialization of addons from Project to it's own AddonsFactory object
• give each addon it's own AddonDiscovery instance, to look for child addons
• give each addon it's own AddonsFactory instance, to instantiate any child addons
• add acceptance test verifying addon isolation
• add new addon hook: setupPreprocessorRegistry(type, registry)
• move registry to models/
• add more acceptance tests exercising nested plugins
• implement support for nested addons contributing to built output, and handling for addons appearing more than once in the graph, including two different versions of the same addon (keeping current semantics of one addon per build output, and last added "wins")
• unit tests for setupPreprocessorRegistry hook
• unit tests for AddonsDiscovery
• unit tests for AddonsFactory
• inline docs for setupPreprocessorRegistry hook
• inline docs for AddonsDiscovery
• inline docs for AddonsFactory
• verify with addon that has HTMLBars templates in the addon (requires ember-cli-htmlbars 0.7.4 or above): Demo App
• document changes necessary to addons to take advantage of this.
• Update to Ember 1.10 by default.

[rwjblue]

This is looking very good.

[jayphelps]

[lukemelia]

I believe this is now feature complete. Still needs tests and docs, as I've added to the checklist, but it would be a great time to provide any feedback on the implementation.

[jayphelps]

RAD. Will test tomorrow. I've got a bunch of projects and addons working around this that I can test against.

[lukemelia]

@jayphelps note that this is a breaking change. Addons may need to be updated to implement setupPreprocessorRegistry appropriately.

[rwjblue]

Removed WIP label.

@ember-cli/owners - Speak now or forever hold your peace...

[twokul]

@lukemelia big OS ❤️ from me to you, Sir.

[chadhietala]

[trabus]

Awesome work @lukemelia! 👍

[lukemelia]

This was a team effort. @rwjblue provided great guidance and took it over the finish line. Also, props to @chrislopresto for helping me with some testing and thinking on this, and to @gshackles at @ololabs for funding the early work on this. Glad to see it landing!

[joostdevries]

@lukemelia this is intensely awesome, a very important iteration on the whole addon concept.
My initial thoughts/questions:

• How do you define the division of labour between AddonDiscovery and AddonFactory, wouldn't a single class make more sense? From my point of view it's very nice to have a single component in charge of managing addons and to initialize that component for every project or addon. I don't really see why we'd need two separate classes.
• Is it still needed to even register addonPackages on the Project? Couldn't we completely delegate this this component?

[rwjblue]

Added unit tests for AddonDiscovery model.

[lukemelia]

@joostdevries I could go either way on the separation of AddonDiscovery and AddonsFactory. Conceptually, it seems to me that discovering dependent addons is a separate thing from instantiating a set of addons in DAG-powered order. Regarding registering addonPackages on the Project... yes I think we ultimately should have the encapsulation be complete. I was trying to take as small a step here as I could with respect to number of APIs we were breaking.

[stefanpenner]

This looks awesome. I am going to set some time aside tonight to thoroughly review this.

[rwjblue]

@stefanpenner - I'd like to land this and release 0.2.0-beta.1 soon (once Travis passes), that way folks have some time to provide feedback on the beta (and allows others to help out easier since it wouldn't be blocked in this PR any longer).

[joostdevries]

I was trying to take as small a step here as I could with respect to number of APIs we were breaking.

@lukemelia I'm with you on that. Again, this looks amazing.

[jayphelps]

[cibernox]

Is that the end of the painful manual package.json upgrade review?

[rwjblue]

@cibernox - Not sure, you will still need to review package.json and bower.json updates, but they at least will not require you to manually remove broccoli-ember-hbs-template-compiler and change the Ember version from 1.8.0.

[cibernox]

I thought that core stuff like broccoli-asset-rev or ember-cli-6to5 would be nested in ember-cli itself, and therefore I won't need to take care of resolving conflicts on them.

[rwjblue]

@cibernox - Nope, that is not being done in this PR. Those addons will continue living in your apps package.json, because it needs to be trivially possible to opt out of them.

[cibernox]

Undestood

[slindberg]

Huge thanks @lukemelia, @rwjblue, and everyone else involved! 👏