v2 addon by default #985
v2 addon by default #985
Conversation
Co-authored-by: MrChocolatine <[email protected]>
|
|
||
| ## Detailed design | ||
|
|
||
| `@embroider/addon-blueprint` will remain its own repo. `ember addon` will use this by default without a flag at some point. |
There was a problem hiding this comment.
of note, ember-cli 5.4 broke the @embroider/addon-blueprint.
So, that's the biggest risk with using an external blueprint with no other changes to process.
The details of flags of how blueprints are created (packageManager in this case vs yarn or npm flags) don't feel exactly like public API, so I'm sure that makes this more complicated.
| `@embroider/addon-blueprint` has been in progress for a while, it's good stuff. | ||
|
|
||
|
|
||
| ## Motivation |
There was a problem hiding this comment.
motivation for having external blueprint, rather than built in to ember-cli?
- easiest to test
- ember-cli's test suite is already quite slow (due to tons of tests)
- can be independently versioned, patched, etc
| ## Detailed design | ||
|
|
||
| `@embroider/addon-blueprint` will remain its own repo. `ember addon` will use this by default without a flag at some point. | ||
|
|
There was a problem hiding this comment.
the addon-blueprint would likely need to test against a range of ember-cli versions, rather than what it does today, which is always use latest.
this would be good to do anyway (today) as it gives us a solid understanding of what is supported.
Afaik, the minimum supported ember-cli must be at least 5.3 for full typescript support -- the v2 addon blueprint has been ahead of ember-cli in this area for a bit, but in 5.3 alignment occurred and we don't want to have incoherence between the v2 addon blueprint and the generated app blueprint that's used for the test-app in the v2 addon blueprint as that is still under ember-cli's control
|
|
||
| `@embroider/addon-blueprint` will remain its own repo. `ember addon` will use this by default without a flag at some point. | ||
|
|
||
| ## How we teach this |
There was a problem hiding this comment.
starting another thread based on the above, (v2 addon being separate, test-app still controlled by ember-cli) -- it could make sense to pull out the other blueprints to separate packages as well.
This begs the question, how do we ensure that ember-cli (at whatever version) 5 years from now still generates the same blueprint? An answer could be that when published, ember-cli uses a fixed version of the blueprint libraries (i.e.: no ^ or ~ ranges)
|
|
||
| ## How we teach this | ||
|
|
||
| > What names and terminology work best for these concepts and why? How is this |
There was a problem hiding this comment.
also, we'll need ember-cli to formally allow blueprints to implement their own flags
ef4
added
S-Exploring
|
Would like to codify a testing story where Ember used as library without having to have a separate app. |
No description provided.