-
Notifications
You must be signed in to change notification settings - Fork 109
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
2.0 upgrade guide #379
2.0 upgrade guide #379
Conversation
### Embroider v2 Addon Format support | ||
|
||
ember-auto-import 2.0 handles Embroider v2-formatted addons for apps that aren't yet using Embroider. | ||
|
||
This is potentially breaking because it adds more stuff to the webpack config that people could have been manually controlling before. Specifically: | ||
|
||
- v2 addons are allowed to import css, so we add the appropriate webpack loaders | ||
- v2 addons are allowed to contain inline templates, decorators, and embroider macros, so all of these are now supported by ember-auto-import |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is huuuuge! 😍
If I'm understanding this right, it means that we can iteratively make our individual in-house addons / engines Embroider-v2-formatted-compatible, without having to also fully migrate the host app in the same swoop, but still reap the build performance improvements by pre-building & publishing the addons / engines to a registry.
Is that correct?
And if so, are there recommended workflows for monorepo setups already? I would like to use the pre-built packages, if there are no local changes, and only live-build them, if changes were made.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that's correct. Addons will be able to port to v2. The only requirement that will impose on apps will be that they take ember-auto-import 2.0.
And if so, are there recommended workflows for monorepo setups already? I would like to use the pre-built packages, if there are no local changes, and only live-build them, if changes were made.
I don't have any examples yet of that kind of workflow, but I would expect that people wouldn't want to commit build artifacts to their repo, so you'd have a dev process analogous to running tsc --watch
that could cover the whole monorepo. It's not going to be expensive, because the kind of transformations you'd do (stripping typescript types, inlining templates, generating setComponentTemplate
) are quite light.
This is the plan for how I want to roll out 2.0. Not everything described in here is implemented at the moment, but it's close.