-
Notifications
You must be signed in to change notification settings - Fork 6.8k
refactor: decouple migrations from CLI devkit #19004
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
Conversation
ff4b390
to
7e74aa6
Compare
We want to refactor our update-tool to no longer rely on specifics from the Angular CLI devkit. This has various benefits: * Ability to run migrations inside Google. * Ability to run migrations in a standalone tool (for people not using the CLI!) * No tight dependency on the CLI devkit API. We could easily switch tools if needed. * Ability to wrap migrations in tslint rules (or other tools). * And potentially more. These are just the ones that came to mind yet.
7e74aa6
to
168b2c1
Compare
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.
Everything looks good to me - good job abstracting so that we can separate out the devkit.
Would it make sense to try and run a migration of an app from 8 to 9 using this new code, just to make sure its sound?
@andrewseguin Thanks for reviewing! Yeah I guess we could do that for testing. The migrations (except for the HammerJS one) should be compatible. The HammerJS one heavily relies on the CLI workspace config etc. |
We want to refactor our update-tool to no longer rely on specifics from the Angular CLI devkit. This has various benefits: * Ability to run migrations inside Google. * Ability to run migrations in a standalone tool (for people not using the CLI!) * No tight dependency on the CLI devkit API. We could easily switch tools if needed. * Ability to wrap migrations in tslint rules (or other tools). * And potentially more. These are just the ones that came to mind yet.
We want to refactor our update-tool to no longer rely on specifics from the Angular CLI devkit. This has various benefits: * Ability to run migrations inside Google. * Ability to run migrations in a standalone tool (for people not using the CLI!) * No tight dependency on the CLI devkit API. We could easily switch tools if needed. * Ability to wrap migrations in tslint rules (or other tools). * And potentially more. These are just the ones that came to mind yet.
* refactor: decouple migrations from CLI devkit (#19004) We want to refactor our update-tool to no longer rely on specifics from the Angular CLI devkit. This has various benefits: * Ability to run migrations inside Google. * Ability to run migrations in a standalone tool (for people not using the CLI!) * No tight dependency on the CLI devkit API. We could easily switch tools if needed. * Ability to wrap migrations in tslint rules (or other tools). * And potentially more. These are just the ones that came to mind yet. * Address feedback
* refactor: decouple migrations from CLI devkit (#19004) We want to refactor our update-tool to no longer rely on specifics from the Angular CLI devkit. This has various benefits: * Ability to run migrations inside Google. * Ability to run migrations in a standalone tool (for people not using the CLI!) * No tight dependency on the CLI devkit API. We could easily switch tools if needed. * Ability to wrap migrations in tslint rules (or other tools). * And potentially more. These are just the ones that came to mind yet. * Address feedback
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
We want to refactor our update-tool to no longer rely
on specifics from the Angular CLI devkit. This has various benefits:
This will be the foundation for our MDC migrations that should run within CLI projects and inside Google. Optionally we can provide a standalone CLI tool that runs the migrations too!