New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Deprecation] Introduce new build file #4286

Merged
merged 6 commits into from Jun 25, 2015

Conversation

Projects
None yet
6 participants
@chadhietala
Member

chadhietala commented Jun 12, 2015

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.

[Breaking] Brocfile should return a function that recieves the project
This will allow EmberApp to call the Brocfile repeatedly and share the project across rebuilds.

@stefanpenner stefanpenner referenced this pull request Jun 12, 2015

Open

Packager #4211

8 of 16 tasks complete
@stefanpenner

This comment has been minimized.

Show comment
Hide comment
@stefanpenner

stefanpenner Jun 12, 2015

Contributor

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

Contributor

stefanpenner commented Jun 12, 2015

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

@stefanpenner

This comment has been minimized.

Show comment
Hide comment
@stefanpenner

stefanpenner Jun 12, 2015

Contributor

The goal of this is to parameterize Project.

I believe @rwjblue has some other ideas.

Contributor

stefanpenner commented Jun 12, 2015

The goal of this is to parameterize Project.

I believe @rwjblue has some other ideas.

@rwjblue

This comment has been minimized.

Show comment
Hide comment
@rwjblue

rwjblue Jun 12, 2015

Contributor

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).

Contributor

rwjblue commented Jun 12, 2015

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

This comment has been minimized.

Show comment
Hide comment
@stefanpenner

stefanpenner Jun 12, 2015

Contributor

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

Contributor

stefanpenner commented Jun 12, 2015

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

@rwjblue

This comment has been minimized.

Show comment
Hide comment
@rwjblue

rwjblue Jun 12, 2015

Contributor

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.

Contributor

rwjblue commented Jun 12, 2015

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.

Show outdated Hide outdated blueprints/addon/files/Brocfile.js Outdated
Show outdated Hide outdated lib/models/builder.js Outdated
@chadhietala

This comment has been minimized.

Show comment
Hide comment
@chadhietala

chadhietala Jun 12, 2015

Member

@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.

Member

chadhietala commented Jun 12, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@stefanpenner

stefanpenner Jun 12, 2015

Contributor

@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

Contributor

stefanpenner commented Jun 12, 2015

@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 chadhietala changed the title from [Breaking] Brocfile should return a function that recieves the project to [Decrecation] Introduce new build file Jun 12, 2015

@chadhietala

This comment has been minimized.

Show comment
Hide comment
@chadhietala

chadhietala Jun 12, 2015

Member

@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.

Member

chadhietala commented Jun 12, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@rwjblue

rwjblue Jun 12, 2015

Contributor

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...

Contributor

rwjblue commented Jun 12, 2015

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

This comment has been minimized.

Show comment
Hide comment
@stefanpenner

stefanpenner Jun 12, 2015

Contributor

@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.

Contributor

stefanpenner commented Jun 12, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@rwjblue

rwjblue Jun 12, 2015

Contributor

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).

Contributor

rwjblue commented Jun 12, 2015

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

This comment has been minimized.

Show comment
Hide comment
@chadhietala

chadhietala Jun 12, 2015

Member

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

Member

chadhietala commented Jun 12, 2015

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

@chadhietala chadhietala changed the title from [Decrecation] Introduce new build file to [Deprecation] Introduce new build file Jun 12, 2015

chadhietala added some commits Jun 12, 2015

@chadhietala

This comment has been minimized.

Show comment
Hide comment
@chadhietala

chadhietala Jun 12, 2015

Member

@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.

Member

chadhietala commented Jun 12, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@chadhietala

chadhietala Jun 21, 2015

Member

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

Member

chadhietala commented Jun 21, 2015

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

Show outdated Hide outdated TRANSITION.md Outdated
Show outdated Hide outdated lib/models/builder.js Outdated
Show outdated Hide outdated lib/models/builder.js Outdated
@stefanpenner

This comment has been minimized.

Show comment
Hide comment
@stefanpenner

stefanpenner Jun 24, 2015

Contributor

tests are unhappy

Contributor

stefanpenner commented Jun 24, 2015

tests are unhappy

Pass a hash to the build file
Instead of passing N arguments to the EmberApp constructur, we should pass a hash so we do not paint our selves into a corner. Internally this is merged from right to left with the developer's options. In other words the developer can completly override the defaults.
@chadhietala

This comment has been minimized.

Show comment
Hide comment
@chadhietala

chadhietala Jun 25, 2015

Member

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

Member

chadhietala commented Jun 25, 2015

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

@stefanpenner

This comment has been minimized.

Show comment
Hide comment
@stefanpenner
Contributor

stefanpenner commented Jun 25, 2015

Show outdated Hide outdated lib/utilities/find-build-file.js Outdated

rwjblue added a commit that referenced this pull request Jun 25, 2015

Merge pull request #4286 from chadhietala/pass-project
[Deprecation] Introduce new build file

@rwjblue rwjblue merged commit d5c840d into ember-cli:master Jun 25, 2015

2 of 3 checks passed

coverage/coveralls Coverage decreased (-0.26%) to 87.89%
Details
continuous-integration/appveyor AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@twokul twokul removed the in progress label Jun 25, 2015

@stefanpenner

This comment has been minimized.

Show comment
Hide comment
@stefanpenner

stefanpenner Jun 25, 2015

Contributor

Yay

Contributor

stefanpenner commented Jun 25, 2015

Yay

@pixelhandler

This comment has been minimized.

Show comment
Hide comment
@pixelhandler

pixelhandler Jul 9, 2015

Contributor

Don't forget to add the defaults when you migrate from 0.2.7.

Contributor

pixelhandler commented on TRANSITION.md in 71f9bd2 Jul 9, 2015

Don't forget to add the defaults when you migrate from 0.2.7.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment