[Deprecation] Introduce new build file

[chadhietala]

To be able to pass around the project instance we need to parameterize the build file. Since Brocfile means something to broccoli we need to create a new build file.

[stefanpenner]

I think we can actually do this via deprecation. We should be able to inspect the imported module.

[stefanpenner]

The goal of this is to parameterize Project.

I believe @rwjblue has some other ideas.

[rwjblue]

Brocfile.js has specific meaning in Broccoli-land, we should not completely change that meaning. What we want is our own thing that replaces Brocfile.js and accepts a project instance. We should just make it a new file (preferably in config/ somewhere).

[stefanpenner]

We could call it ember.js or 'build.js' or something, Potentially at the root or in the config dir.

[rwjblue]

Using ember.js would then reference two different files, one published by Ember itself and one used by ember-cli. We should not continue to overload the same terms/names with different meanings.

[rwjblue]

This is using ember-app and should be ember-addon.

[chadhietala]

@rwjblue Moving it to config gets complicated as you can change the config directory name by passing configPath to EmberApp. So you have a chicken and egg problem when you attempt to look up the build file prior to actually running the build. This could be solved more generically with using a glob pattern e.g. /**/build.js but I have a feeling that build.js is way too generic for us to cut over safely.

I would suggest that we have a new build file in the root of the project called ember-cli-build.js or even <name-of-app>-build.js. The first option I feel has the least chance of overlap.

[stefanpenner]

@chadhietala maybe the global route skips this problem for now? It does make me cringe though.

Ultimately this improvement will need to happen. We just need to nail what it means

[chadhietala]

@stefanpenner I think it's doable we just need a different name or path that we can guarantee will be there and does not have the likelihood to cause collisions.

[rwjblue]

ember-cli-build.js

This is the best option proposed so far. I personally dislike having tons of files in a project root, but if we need an unambiguous thing then this is it...

[stefanpenner]

@chadhietala it is actually ambiguous in config?

@rwjblue I am unsure which is better, root of dir or in config/. Balancing clutter and visibility is a tricky thing. Ultimately it likely will just be up to us to make a choice.

[rwjblue]

Ultimately it likely will just be up to us to make a choice.

Agreed. I'd be perfectly happy removing the configPath option (or making it only applicable to config/environment.js which AFAIK is what it applies to).

[chadhietala]

We use configPath because we have another config folder that cannot change and used for other machinery. So I would be 👎 on that.

[chadhietala]

@rwjblue and @stefanpenner restarting travis, locally my tests are green. We just need to deal the one of hardest problems in programming... naming things. Also I'm wondering if it's necessary to add a test to test the deprecation, logic is pretty straight forward.

[chadhietala]

@rwjblue and @stefanpenner, do you guys have any more thoughts on this?

[stefanpenner]

how about project -> { project: project }

which ends up being:

module.exports = function(defaults) {
  var app = new EmberApp(merge(defaults, {
    ....
  }));

  module.exports = app.toTree();
}

[stefanpenner]

we could also make EmberApp do the merge....

[stefanpenner]

tests are unhappy

[chadhietala]

Everything looks good if we're ok with the drop in code coverage.

[stefanpenner]

@rwjblue r?

[rwjblue]

Throwing here means that we do not allow fallback to Brocfile.js with deprecation, can we have a test that has just a Brocfile.js and confirms that this still works?

[stefanpenner]

Yay