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

Extract ember related blueprints into ember proper #12412

Closed
wants to merge 14 commits into
from

Conversation

Projects
None yet
5 participants
@stefanpenner
Member

stefanpenner commented Sep 30, 2015

This aims to decouple features of ember-cli that are actually tied to ember, this should ease upgrades and also prevent the various blueprints from getting widely out of sync.

This lays the work that will eventually allow us transpose ember repo itself into a well formed add-on.

  • pull ember.js related blueprints into ember
  • decouple most of the blueprints from ember-cli
  • confirm all the blueprints already decoupled work
  • bundle shims (eventually they wont be needed at all)

Several pieces of blueprint functionality are still coupled to ember-cli, they depend on:

  • decouple all blueprints from ember-cli
    • ../../lib/valid-component-name
    • ../addon-import
    • models/blueprint

There are some bootstraping issues, when it comes to app and addonthemselves due to the cyclic nature of this flow. I do believe the simplest is for them to be part of this repo, but that assumption may prove to be wrong.

  • deal with the cyclic nature of ember-cli -> ember -> app blueprint -> ember-cli, likely just by improving the mechanism by which we bootstrap the whole thing
  • app.import the various parts of dist (@rwjblue mind tackling this item?)
  • blueprint test-harness so they can be tested outside of ember-cli themselves
  • ... ?
  • release ember as an npm module

stefanpenner added a commit to ember-cli/ember-cli that referenced this pull request Sep 30, 2015

@stefanpenner stefanpenner referenced this pull request Sep 30, 2015

Closed

remove blueprints that will be provided by: #4909

4 of 5 tasks complete
@rwjblue

This comment has been minimized.

Show comment
Hide comment
@rwjblue

rwjblue Sep 30, 2015

Member

The following blueprints should not be moved into Ember itself:

  • app - This is the default folder structure/scaffolding for an app, and contains little or no Ember version specific information.
  • addon - Same as app.
  • adapter - This is an Ember Data blueprint (not an Ember one).
  • model - Ember Data
  • view - This should likely be in ember-legacy-views

If we do need to defer some of the file contents for app/addon (perhaps things like app/router.js) we can make a custom blueprint for it (in blueprints/router/) and that can move into Ember...

Member

rwjblue commented Sep 30, 2015

The following blueprints should not be moved into Ember itself:

  • app - This is the default folder structure/scaffolding for an app, and contains little or no Ember version specific information.
  • addon - Same as app.
  • adapter - This is an Ember Data blueprint (not an Ember one).
  • model - Ember Data
  • view - This should likely be in ember-legacy-views

If we do need to defer some of the file contents for app/addon (perhaps things like app/router.js) we can make a custom blueprint for it (in blueprints/router/) and that can move into Ember...

@stefanpenner

This comment has been minimized.

Show comment
Hide comment
@stefanpenner

stefanpenner Sep 30, 2015

Member

app - This is the default folder structure/scaffolding for an app, and contains little or no Ember version specific information.
addon - Same as app.

I am unclear about these. As parts of them are somewhat dictated by ember.

Maybe the right course of action for those, is to to split them apart.

Member

stefanpenner commented Sep 30, 2015

app - This is the default folder structure/scaffolding for an app, and contains little or no Ember version specific information.
addon - Same as app.

I am unclear about these. As parts of them are somewhat dictated by ember.

Maybe the right course of action for those, is to to split them apart.

@rwjblue

This comment has been minimized.

Show comment
Hide comment
@rwjblue

rwjblue Sep 30, 2015

Member

Maybe the right course of action for those, is to to split them apart.

Yep, agreed (I mentioned that in #12412 (comment)).

Member

rwjblue commented Sep 30, 2015

Maybe the right course of action for those, is to to split them apart.

Yep, agreed (I mentioned that in #12412 (comment)).

@stefanpenner

This comment has been minimized.

Show comment
Hide comment
@stefanpenner

stefanpenner Sep 30, 2015

Member

another thing is, the pod-layout vs not pod-layout stuff is somewhat dictate by our ember docs. I suspect this is another case where we can parametrize.

Member

stefanpenner commented Sep 30, 2015

another thing is, the pod-layout vs not pod-layout stuff is somewhat dictate by our ember docs. I suspect this is another case where we can parametrize.

@stefanpenner

View changes

Show outdated Hide outdated blueprints/app/files/app/app.js
let App;
Ember.MODEL_FACTORY_INJECTIONS = true;

This comment has been minimized.

@stefanpenner

stefanpenner Sep 30, 2015

Member

@rwjblue for example this line (and this whole file) kinda wants to be in both

@stefanpenner

stefanpenner Sep 30, 2015

Member

@rwjblue for example this line (and this whole file) kinda wants to be in both

This comment has been minimized.

@rwjblue

rwjblue Sep 30, 2015

Member

Sure, as I mentioned in #12412 (comment) we will need to make a blueprint for this (and likely router.js) then invoke that blueprint from app. The app.js blueprint lives in Ember, but the app structure blueprint lives in ember-cli...

@rwjblue

rwjblue Sep 30, 2015

Member

Sure, as I mentioned in #12412 (comment) we will need to make a blueprint for this (and likely router.js) then invoke that blueprint from app. The app.js blueprint lives in Ember, but the app structure blueprint lives in ember-cli...

@stefanpenner

View changes

Show outdated Hide outdated blueprints/app/files/bower.json
{
"name": "<%= name %>",
"dependencies": {
"ember": "2.0.0",

This comment has been minimized.

@stefanpenner

stefanpenner Sep 30, 2015

Member

As embers version changes, as do these dependencies. (once we drop bower though, that problem gets much nicer)

@stefanpenner

stefanpenner Sep 30, 2015

Member

As embers version changes, as do these dependencies. (once we drop bower though, that problem gets much nicer)

@stefanpenner

View changes

Show outdated Hide outdated blueprints/app/files/config/environment.js
@@ -0,0 +1,47 @@
/* jshint node: true */
module.exports = function(environment) {

This comment has been minimized.

@stefanpenner

stefanpenner Sep 30, 2015

Member

this is totally something ember-cli specific

@stefanpenner

stefanpenner Sep 30, 2015

Member

this is totally something ember-cli specific

@stefanpenner

This comment has been minimized.

Show comment
Hide comment
@stefanpenner

stefanpenner Sep 30, 2015

Member

Drawing the boundaries is kinda hard... hmm

Member

stefanpenner commented Sep 30, 2015

Drawing the boundaries is kinda hard... hmm

@stefanpenner

View changes

Show outdated Hide outdated blueprints/addon/files/ember-cli-build.js
@@ -0,0 +1,17 @@
/* global require, module */
var EmberAddon = require('ember-cli/lib/broccoli/ember-addon');

This comment has been minimized.

@stefanpenner

stefanpenner Sep 30, 2015

Member

i wonder if ember-addon and ember-app really want to be seperate modules... This hole NPM crap makes this so tricky

@stefanpenner

stefanpenner Sep 30, 2015

Member

i wonder if ember-addon and ember-app really want to be seperate modules... This hole NPM crap makes this so tricky

stefanpenner added a commit to ember-cli/ember-cli that referenced this pull request Sep 30, 2015

stefanpenner added a commit to ember-cli/ember-cli that referenced this pull request Oct 2, 2015

stefanpenner added a commit to ember-cli/ember-cli that referenced this pull request Oct 2, 2015

@stefanpenner stefanpenner referenced this pull request Oct 6, 2015

Closed

Ember 2.0 #4671

4 of 7 tasks complete

@mmun mmun self-assigned this Dec 22, 2015

return path.join(__dirname, 'blueprints');
},
treeFor: function(type) {

This comment has been minimized.

@rwjblue

rwjblue Dec 27, 2015

Member

Use treeForVendor instead of treeFor + guard for type === 'vendor'.

@rwjblue

rwjblue Dec 27, 2015

Member

Use treeForVendor instead of treeFor + guard for type === 'vendor'.

@@ -24,6 +27,7 @@
"bower": "~1.3.2",
"chalk": "^0.5.1",
"ember-cli": "^1.13.13",
"ember-cli-blueprint-test-helpers": "ember-cli/ember-cli-blueprint-test-helpers#qunit",

This comment has been minimized.

@rwjblue

rwjblue Dec 27, 2015

Member

I'd like to land the changes from ember-cli/ember-cli-blueprint-test-helpers#qunit in a release version before merging this PR.

@rwjblue

rwjblue Dec 27, 2015

Member

I'd like to land the changes from ember-cli/ember-cli-blueprint-test-helpers#qunit in a release version before merging this PR.

@@ -31,6 +35,7 @@
"emberjs-build": "0.5.3",
"express": "^4.5.0",
"finalhandler": "^0.4.0",
"fs-extra": "^0.26.3",

This comment has been minimized.

@rwjblue

rwjblue Dec 27, 2015

Member

This is used from blueprints/route/index.js so it needs to be in dependencies.

@rwjblue

rwjblue Dec 27, 2015

Member

This is used from blueprints/route/index.js so it needs to be in dependencies.

@rwjblue

This comment has been minimized.

Show comment
Hide comment
@rwjblue

rwjblue Dec 27, 2015

Member

This is looking very good, I left a few minor inline comments. My main concerns at this point are:

  • Should the *-test blueprints be moved into ember-cli-qunit instead of Ember itself? It seems to me that this is the right choice and it would be unfortunate to have to move them twice (into Ember then out into ember-cli-qunit later).
  • Can you provide a demo/test repo with the required setup to play with this? How does it work with various ember-cli versions?
  • We are defining our own shims here (which is good), does that have negative interaction on using ember-cli-shims also? Which one wins if you have both?
Member

rwjblue commented Dec 27, 2015

This is looking very good, I left a few minor inline comments. My main concerns at this point are:

  • Should the *-test blueprints be moved into ember-cli-qunit instead of Ember itself? It seems to me that this is the right choice and it would be unfortunate to have to move them twice (into Ember then out into ember-cli-qunit later).
  • Can you provide a demo/test repo with the required setup to play with this? How does it work with various ember-cli versions?
  • We are defining our own shims here (which is good), does that have negative interaction on using ember-cli-shims also? Which one wins if you have both?
@homu

This comment has been minimized.

Show comment
Hide comment
@homu

homu Dec 28, 2015

Contributor

☔️ The latest upstream changes (presumably #12757) made this pull request unmergeable. Please resolve the merge conflicts.

Contributor

homu commented Dec 28, 2015

☔️ The latest upstream changes (presumably #12757) made this pull request unmergeable. Please resolve the merge conflicts.

@Turbo87

This comment has been minimized.

Show comment
Hide comment
@Turbo87

Turbo87 Feb 19, 2016

Member

Should the *-test blueprints be moved into ember-cli-qunit instead of Ember itself? It seems to me that this is the right choice and it would be unfortunate to have to move them twice (into Ember then out into ember-cli-qunit later).

IMHO this project should use the same approach as taken in emberjs/data#4167. i.e. providing both qunit and mocha blueprints from this repo.

Member

Turbo87 commented Feb 19, 2016

Should the *-test blueprints be moved into ember-cli-qunit instead of Ember itself? It seems to me that this is the right choice and it would be unfortunate to have to move them twice (into Ember then out into ember-cli-qunit later).

IMHO this project should use the same approach as taken in emberjs/data#4167. i.e. providing both qunit and mocha blueprints from this repo.

@rwjblue

This comment has been minimized.

Show comment
Hide comment
@rwjblue

rwjblue Feb 19, 2016

Member

Yes, agreed (we had come to the same conclusion but forgot to update here).

Member

rwjblue commented Feb 19, 2016

Yes, agreed (we had come to the same conclusion but forgot to update here).

@Turbo87

This comment has been minimized.

Show comment
Hide comment
@Turbo87

Turbo87 Feb 22, 2016

Member

@stefanpenner can you explain what you did here?

Member

Turbo87 commented on 2df6f0e Feb 22, 2016

@stefanpenner can you explain what you did here?

@Turbo87

This comment has been minimized.

Show comment
Hide comment
@Turbo87

Turbo87 Mar 15, 2016

Member

@rwjblue @stefanpenner I think this can be closed now that #13029 has been merged

Member

Turbo87 commented Mar 15, 2016

@rwjblue @stefanpenner I think this can be closed now that #13029 has been merged

@rwjblue rwjblue closed this Mar 15, 2016

@rwjblue rwjblue deleted the addonified branch Mar 15, 2016

@rwjblue

This comment has been minimized.

Show comment
Hide comment
@rwjblue

rwjblue Mar 15, 2016

Member

Thanks for the reminder

Member

rwjblue commented Mar 15, 2016

Thanks for the reminder

@stefanpenner

This comment has been minimized.

Show comment
Hide comment
Member

stefanpenner commented Mar 15, 2016

👍

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