feat(language-service): add code reactoring action to migrate @Input to signal input
#57214
Conversation
dcb93e8 to
f77a1f2
Compare
f77a1f2 to
f796f4a
Compare
2b0d49e to
9f74be3
Compare
packages/core/schematics/migrations/signal-migration/src/migration.ts
Outdated
Show resolved
Hide resolved
| return node; | ||
| } | ||
|
|
||
| function getBeforeMigrateHookToFilterAllUnrelatedInputs( |
There was a problem hiding this comment.
This is really difficult to understand because of how it mutates the known inputs and results prior to running the migration on them. It's really hard to follow that this is happening when looking at the actual migration code that calls the hook: from there, it looks like the hook might just be a no-op for the migration since it's a void function. Can we change this to have the "beforeMigration" actually return an object with the modified known inputs and results?
Alternatively, can we document this "beforeMigrateHook" either by renaming it to something that indicates the objects being passed in can be/are mutated or add some jsdoc to the function or comments at the call location in migration.ts?
There was a problem hiding this comment.
It was done that way to keep the migration code more decoupled from the language service, and it's indeed leveraging a few implementation details.
You are right though. It doesn't feel great. I will have a look, but don't want to make super invasive changes right now since I also need to figure out the same problem when trying to limit to an directory in ng update.
There was a problem hiding this comment.
I will keep that comment open, and address it in a follow-up, tomorrow. Want to get things moving for now.
packages/language-service/src/refactorings/convert_to_signal_input.ts
Outdated
Show resolved
Hide resolved
packages/language-service/src/refactorings/convert_to_signal_input.ts
Outdated
Show resolved
Hide resolved
This allows us to split up the BUILD rules a bit further, so that refactorings can be their own BUILD target. This is beneficial as e.g. refactorings may rely on migration code from Angular core etc. and this allows for more fine-grained visibility and a better conceptual split.
…chronously VSCode explicitly split code actions into two stages: - what actions are active? - what are the edits, if the user presses the button. The latter stage may take longer to compute complex edits, perform analysis. This stage is currently implemented via our non-LSP standard `applyRefactoring` method. We should make it asynchronous, so that it can easily integrate with migrations that aren't synchronous/or compute in parallel. Long-term we may want to revisit this given integration in 1P with the language service as an actual TS server plugin; but it's not necessary right now and we shouldn't block the effort on this for now.
…` to signal-input (experimental at this point) Language service refactoring action that can convert `@Input()` declarations to signal inputs. The user can click on an `@Input` property declaration in e.g. the VSCode extension and ask for the input to be migrated. All references, imports and the declaration are updated automatically.
This allows us to bundle e.g. the signal input migration into language-service without duplicating code. Rollup with Bazel may end up duplicating because it isn't able to associate the local sources with the linked modules from `node_modules/@angular/compiler-cli`.
9f74be3 to
80f2c8c
Compare
…ts asynchronously Feedback
…`@Input` to signal-input Feedback
80f2c8c to
eb28838
Compare
|
This PR was merged into the repository by commit 82f4590. The changes were merged into the following branches: main |
…chronously (#57214) VSCode explicitly split code actions into two stages: - what actions are active? - what are the edits, if the user presses the button. The latter stage may take longer to compute complex edits, perform analysis. This stage is currently implemented via our non-LSP standard `applyRefactoring` method. We should make it asynchronous, so that it can easily integrate with migrations that aren't synchronous/or compute in parallel. Long-term we may want to revisit this given integration in 1P with the language service as an actual TS server plugin; but it's not necessary right now and we shouldn't block the effort on this for now. PR Close #57214
…` to signal-input (#57214) (experimental at this point) Language service refactoring action that can convert `@Input()` declarations to signal inputs. The user can click on an `@Input` property declaration in e.g. the VSCode extension and ask for the input to be migrated. All references, imports and the declaration are updated automatically. PR Close #57214
This allows us to bundle e.g. the signal input migration into language-service without duplicating code. Rollup with Bazel may end up duplicating because it isn't able to associate the local sources with the linked modules from `node_modules/@angular/compiler-cli`. PR Close #57214
|
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. |
(experimental action for now; migration is not done/finalized yet)
Language service refactoring action that can convert
@Input()declarations to signal inputs.The user can click on an
@Inputproperty declaration in e.g. the VSCode extension and askfor the input to be migrated. All references, imports and the declaration are updated automatically.
NOTE: Currently based on top of: #57562