Extract ember related blueprints into ember proper

[stefanpenner]

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

[rwjblue]

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]

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]

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

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

[stefanpenner]

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]

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

[rwjblue]

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]

Drawing the boundaries is kinda hard... hmm

[stefanpenner]

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

[rwjblue]

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

[rwjblue]

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]

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

[Turbo87]

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 warp-drive-data/warp-drive#4167. i.e. providing both qunit and mocha blueprints from this repo.

[rwjblue]

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

[Turbo87]

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

[rwjblue]

Thanks for the reminder

[stefanpenner]

👍