stefanpenner/ember-cli — pull request #2693 by clekstro (2014-12-07 16:05:15+00:00)
Title: Ensure last loaded blueprint takes precedence

### Background
During the course of developing my first [addon](https://github.com/fauxton/ember-cli-mocha-coffeescript) (which I was encouraged to write by @rwjblue and @dgeb [here](https://github.com/switchfly/ember-cli-mocha/issues/12)), I've come across an issue and tried my best to solve it.

According to the [guides](http://www.ember-cli.com/#developing-addons-and-blueprints), when resolving the blueprint to use for a given generator command, the last loaded addon's blueprint should take precedence:
>
The last loaded blueprint wins with respect to overriding existing (same name) blueprints that come with Ember or other addons (according to package load order.)
>

The load order, as described in the docs, can be manually determined through the use of `before` and `after` within the `ember-addon` section of `package.json`:

```js
{
"ember-addon": {
"after": "ember-cli-coffeescript"
}
}
```
### Expected Behavior

While attempting to overwrite the blueprints used by [ember-cli-coffeescript](https://github.com/kimroen/ember-cli-coffeescript/tree/master/blueprints), I was unable to simply define the blueprints in question and have them automatically override those of the other plugins, in spite of specifying my addon be loaded after `ember-cli-coffeescript`'s.

### Cause
I can confirm that the code used to determine the load order is functioning as it should; I can see my plugin output later in the when running `DEBUG=ember-cli:* ember g acceptance-test foo`:

```bash
ember-cli:project addon: Ember CLI Coffeescript Addon +0ms
ember-cli:project addon: Ember CLI Mocha CoffeeScript +0ms
```

I decided to switch the `after` configuration to `before` to see if the behavior changed, and, voila! My addon's blueprints were generating the expected output. So the blueprints are loading in the exact opposite order as expected!

As the load order of the plugins is correct, I managed to stumble over how Ember-CLI looks up blueprints and find the issue. A project loads blueprints using the `addonBlueprintLookupPaths` method in [lib/models/project.js](https://github.com/stefanpenner/ember-cli/blob/master/lib/models/project.js#L272), which traverses the addons (ordered via the dependency graph), adding the path of each addon to an array.

This array is referenced by the method actually doing the blueprint lookup [here](https://github.com/stefanpenner/ember-cli/blob/master/lib/models/blueprint.js#L974). This code relies on the blueprint paths being in the proper order, as it simply iterates over the array of paths, finding the *first* matching blueprint, which is used to output generated content.

### Resolution
In order for blueprints to be loaded in the correct order, that is, to load an addon's blueprint first that is *lower* in the dependency graph, the blueprint paths must be traversed in the opposite order, starting with the last loaded plugin and ending with the first.

I have simply modified the `addonBlueprintLookupPaths` method to reverse the array of dependencies before iteration, which results in the expected behavior.

I have also added a test case around this, but as I'm new to the project, I'm not sure if this is how it should be done. This introduced a little bit of churn in the tests (adding new addons that use the before/after hooks caused previous tests reliant on the order to be changed), so I'd welcome some feedback if this isn't ideal.