MU addons must generate a MU dummy app #7667
Conversation
| module.exports = { | ||
| browsers | ||
| browsers: [ |
There was a problem hiding this comment.
Looking at this diff I've realized that the module-unification-app blueprint is outdate compared with the regular app blueprint. We need to come up with a system that reuses as much as possible from the standard blueprint and only swaps the indispensable files, so the chances of this happening again is lower.
There was a problem hiding this comment.
module-unification-app blueprint is outdate compared with the regular app blueprint
#7595 aims to address this by re-using the same config/targets.js fixture for both app and module-unification-app blueprints testing.
Also I've been working on reducing duplication between these blueprints(#7500) but it was blocked due to bad testing story(I believe).
cibernox
force-pushed
the
generate-a-mu-dummy-app-for-mu-addongs
branch
from
dffbc98
to
d3f60e9
Compare
| @@ -40,13 +40,12 @@ | |||
| "ember-load-initializers": "^1.0.0", | |||
| "ember-maybe-import-regenerator": "^0.1.6", | |||
| "ember-resolver": "^4.0.0", | |||
| "ember-source": "~3.1.0-beta.1", | |||
| "ember-source": "http://builds.emberjs.com/canary.tgz", | |||
There was a problem hiding this comment.
This URL is out of date. I don't think we should ever be using it, /cc @rwjblue yes?
There was a problem hiding this comment.
Also at
for MU apps.
There was a problem hiding this comment.
Confirm. We need to fetch the current URL each time (via ember-source-channel-url which returns a promise)
There was a problem hiding this comment.
@rwjblue Any guidance how to get the ember-source-channel-url at build time? Specially about how to handle it in testing, where we shouldn't rely on the network.
| @@ -0,0 +1,13 @@ | |||
| import Resolver from 'ember-resolver/resolvers/fallback'; | |||
There was a problem hiding this comment.
I suggest we should have this use the glimmer wrapper instead of the fallback resolver:
import Resolver from 'ember-resolver/resolvers/glimmer-wrapper';The glimmer wrapper only implements module unification rules. The fallback is only needed if you have classic addons.
There was a problem hiding this comment.
I think all apps have classic addons (literally all addons are “classic” right now).
There was a problem hiding this comment.
The dummy app of an brand new module unification addon should not have any classic addons.
There was a problem hiding this comment.
Definitely seems ideal, but I highly doubt it is the current state.
There was a problem hiding this comment.
What is the consensus here?
There was a problem hiding this comment.
Ok! We had some more discussion. Lets stick with the fallback resolver. We should use the fallback setup as described at https://github.com/rwjblue/ember-module-migrator#running-module-unification-with-fallback-to-classic-app-layout. We want to use this setup for MU apps since there are still classic addons in the default package.json and it is reasonable to expect they work out of the box.
I suggest that we should remove the fallback setup before we remove any feature flags here. I've added that step to our blocker list for removing the feature flags.
| Resolver | ||
| }); | ||
|
|
||
| loadInitializers(App, config.modulePrefix + "/src/init"); |
There was a problem hiding this comment.
Per the fallback setup instructions at https://github.com/rwjblue/ember-module-migrator#running-module-unification-with-fallback-to-classic-app-layout another loadInitializers line is needed here that loads addon initializers in the app folder.
There was a problem hiding this comment.
This same addition is needed at
|
In https://github.com/ember-cli/ember-cli/blob/master/blueprints/module-unification-addon/files/tests/test-helper.js#L1 the import must be from |
cibernox
force-pushed
the
generate-a-mu-dummy-app-for-mu-addongs
branch
from
d3f60e9
to
49d0b16
Compare
|
This is ready for a second review |
|
Thank you @cibernox!! |
/cc @rwjblue @mixonic