Conversation
Co-authored-by: MrChocolatine <47531779+MrChocolatine@users.noreply.github.com>
ef4
added
S-Exploring
|
Would like to codify a testing story where Ember used as library without having to have a separate app. |
Co-authored-by: Jon Johnson <jon.johnson@ucsf.edu>
|
TODO:
|
kategengler
left a comment
kategengler
left a comment
There was a problem hiding this comment.
I think generally the RFC needs more prose explaining the goals of the blueprint and less of the specifics of files.
It probably needs more of the documentation that we need to write anyway about how to use a v2 addon blueprint to build or upgrade an addon.
|
|
||
| **V1 addons** get rebuilt by every consuming app, which is slow and couples addon builds to app builds. | ||
|
|
||
| **The original V2 blueprint** fixed the build problem but required a monorepo and manual configuration. It also lacked TypeScript/Glint integration and modern Ember patterns. |
There was a problem hiding this comment.
There was no RFC for this original v2 addon blueprint though, so I'm not sure it is worth mentioning here. The motivation is just to have a blueprint and make it the default.
|
|
||
| ### Migration | ||
|
|
||
| Existing addons are unaffected. New addons get the new blueprint automatically. Existing addons can migrate by generating a new project and copying relevant files, or using `npx ember-cli@latest addon <name> --blueprint @ember/addon-blueprint`. |
There was a problem hiding this comment.
Similar to the v2 app blueprint, this probably needs a plan for ember-cli-update to continue working (so we need to document how the blueprints to specify and probably store in the ember-cli-update config.
Will there be a codemod?
| - Update the Ember Guides and CLI docs to reference the new blueprint | ||
| - The blueprint README covers customization, publishing, and multi-version support | ||
| - Provide migration guides for v1 and v2 addon authors | ||
|
|
There was a problem hiding this comment.
Blueprints are living. The specifics of files within this document may quickly become irrelevant. I think the RFC in general should talk more about the goals of those configurations than the details.
I also propose we add parallel .md files to the blueprint explaining config files and setup. Comments could also work but would potentially cause conflicts on updates. We could also offer and opt-out to not generate them.
Co-authored-by: Katie Gengler <katie@kmg.io>
6 participants
rendered