-
Notifications
You must be signed in to change notification settings - Fork 26.2k
refactor(core): allow developers to select static-query migration strategy #29876
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
refactor(core): allow developers to select static-query migration strategy #29876
Conversation
devversion
commented
Apr 12, 2019
•
edited
Loading
edited
- See individual commits
d34c968
to
0b392d4
Compare
3986080
to
d851fb6
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.
LGTM once message is fixed
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.
looks like a clever way to make the prompts work from core
Currently for Angular Bazel projects, NGC needs to be run in the "postinstall" NPM script in order to generate required summary files. We need to update the postinstall `tsconfig` to not check/re-build the `@angular/core` schematic code which has transitive dependencies which are only available inside of a CLI project. As this is not guaranteed to be the case with Angular Bazel projects, we need to make sure that we don't check/re-build these files.
…ategy Currently there are two available migration strategies for the `static-query` schematic. Both have benefits and negatives which depend on what the developer prefers. Since we can't decide which migration strategy is the best for a given project, the developer should be able to select a specific strategy through a simple choice prompt. In order to be able to use prompts in a migration schematic, we need to take advantage of the "inquirer" package which is also used by the CLI schematic prompts (schematic prompts are usually only statically defined in the schema). Additionally the schematic needs to be made "async" because with prompts the schematic can no longer execute synchronously without implementing some logic that blocks the execution.
…sheets Currently the `template-strategy` for the static query migration uses the Angular compiler in order to determine the query timing. This is problematic as the AngularCompilerProgram also collects metadata for referenced component stylesheets which aren't necessarily present. e.g. in a CLI project the component can reference a Sass file. It's not guaranteed that the standalone Angular compiler plugin supports Sass without custom logic that is brought in by the Angular CLI webpack plugin. In order to avoid any failures for invalid stylesheets, we just disable normalizing of all referenced stylesheets.
…ion strategy Address feedback
d851fb6
to
bf7dd9b
Compare
Issues syncing this in google3, will discuss with other googlers. |
Was able to fix google3 downstream. Good to merge. |
…ategy (#29876) Currently there are two available migration strategies for the `static-query` schematic. Both have benefits and negatives which depend on what the developer prefers. Since we can't decide which migration strategy is the best for a given project, the developer should be able to select a specific strategy through a simple choice prompt. In order to be able to use prompts in a migration schematic, we need to take advantage of the "inquirer" package which is also used by the CLI schematic prompts (schematic prompts are usually only statically defined in the schema). Additionally the schematic needs to be made "async" because with prompts the schematic can no longer execute synchronously without implementing some logic that blocks the execution. PR Close #29876
…sheets (#29876) Currently the `template-strategy` for the static query migration uses the Angular compiler in order to determine the query timing. This is problematic as the AngularCompilerProgram also collects metadata for referenced component stylesheets which aren't necessarily present. e.g. in a CLI project the component can reference a Sass file. It's not guaranteed that the standalone Angular compiler plugin supports Sass without custom logic that is brought in by the Angular CLI webpack plugin. In order to avoid any failures for invalid stylesheets, we just disable normalizing of all referenced stylesheets. PR Close #29876
Currently for Angular Bazel projects, NGC needs to be run in the "postinstall" NPM script in order to generate required summary files. We need to update the postinstall `tsconfig` to not check/re-build the `@angular/core` schematic code which has transitive dependencies which are only available inside of a CLI project. As this is not guaranteed to be the case with Angular Bazel projects, we need to make sure that we don't check/re-build these files. PR Close angular#29876
…ategy (angular#29876) Currently there are two available migration strategies for the `static-query` schematic. Both have benefits and negatives which depend on what the developer prefers. Since we can't decide which migration strategy is the best for a given project, the developer should be able to select a specific strategy through a simple choice prompt. In order to be able to use prompts in a migration schematic, we need to take advantage of the "inquirer" package which is also used by the CLI schematic prompts (schematic prompts are usually only statically defined in the schema). Additionally the schematic needs to be made "async" because with prompts the schematic can no longer execute synchronously without implementing some logic that blocks the execution. PR Close angular#29876
…sheets (angular#29876) Currently the `template-strategy` for the static query migration uses the Angular compiler in order to determine the query timing. This is problematic as the AngularCompilerProgram also collects metadata for referenced component stylesheets which aren't necessarily present. e.g. in a CLI project the component can reference a Sass file. It's not guaranteed that the standalone Angular compiler plugin supports Sass without custom logic that is brought in by the Angular CLI webpack plugin. In order to avoid any failures for invalid stylesheets, we just disable normalizing of all referenced stylesheets. PR Close angular#29876
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. |