Addons autoload generic addon with no main defined

[jakecraige]

Addons will autoload folders in the treeFor hook with the same name if no
ember-addon + main file is specified. They can also export an object instead
of a function that will be extended off of the Addon constructor.

In AddonLookup I am using the try-catch to allow addon folders with no index.js
defined to still be found and used. This is different than how the blueprints
have it implemented here.
This same thing could likely be implemented in a separate PR to not require
blueprints have an empty index.js file.

A few (related?)quesions:
Should we have deprecation warnings on ember-addon-main and/or exporting
a function instead of an object from addons.

I'm for deprecating them both as it's just more to maintain later. I'd rather
have a single path for addons instead of allowing each one to do things different.

[stefanpenner]

can we use resolve module instead of the try/catch?

[jakecraige]

@stefanpenner I made the update using resolve.sync which still requires a try catch. The reason I used the sync is that initializeAddons is currently sync and it would mess with all the places that call it. I could do that if necessary though(only 4 places)

[rwjblue]

I made a few suggestions, and we need to add unit tests for Addon, but this is looking pretty good to me so far.

[rwjblue]

Also, I am OK with deprecating ember-addon-main (as long as it works for a version or two with a console warning on inclusion), but we definitely cannot avoid the typeof constructor === 'function' check. If an addon did not want to extend our internal Addon class it would return it's own constructor, which is a function. Thats why that check is there.

[jakecraige]

@rjackson changes made and build passing. Let me know what you think

[rwjblue]

Can you explain the difference between this.root and this._root here?

[jakecraige]

I wanted the addon author to be able to specify their own root if necessary. I'm not entirely sure if there is a good reason that someone would do that, but that's why. It's possible that would never happen and this could be removed.

[jakecraige]

I suppose they could specify some subdir and keep their treePaths dir relative to that if they wanted.

module.exports = {
  root: path.join(__dirname, 'dist'),
  treePaths: {
    app: 'ember-addon-app'
  }
}

[rwjblue]

I think at that point I would suggest just make a custom treeFor. I'd rather not have both _root and root. It confuses me (I know, I'm a simpleton).

[jakecraige]

@rjackson Yeah I can see how it would be and it doesn't really add much value. Removed

[rwjblue]

Looks good. Can you squash?

[jakecraige]

@rjackson done

[rwjblue]

LGTM, and simplifies addons quite a bit (requires a TON less boilerplate for default setups).

@stefanpenner - Care to +1/-1?

[rwjblue]

Can you rebase?

[jakecraige]

@rwjblue done

[dustinfarris]

If I want to add an 'included' function (for custom app.imports), can I use the object export strategy? Or am I forced to revert to a function?

[jakecraige]

@dustinfarris you should be able to just include the included on the object export

module.exports  = {
  included: function(name) {
    /// ...
  }
}