If a file ends up in multiple programs, the unused imports migration was counting it twice. This was fine since the string replacements were handling it correctly, but it was printing out incorrect data.
These changes rework the migration to de-duplicate the replacements and produce the data from the de-duplicated results.
PR Close#59656
We previously did count forcibly ignored queries as incompatible. This
resulted in incorrect migration stats that are printed upon migration
completion.
See: #58657
PR Close#59463
In v19 we added a warning about unused standalone imports, however we didn't do anything about existing code which means that users have to clean it up manually. These changes add the `ng g @angular/core:cleanup-unused-imports` schematic which will remove the unused dependencies automatically.
There isn't any new detection code since all the manipulations are based on the produced diagnostics, but there's a bit of code to remove the import declarations from the file as well.
Fixes#58849.
PR Close#59353
Fixes that in some cases the internal version of the migration was dropping code when all the statements after the `super` call are deleted.
PR Close#58959
Priori to this commit, initializer functions with dependencies were not migrated correctly.
With this commit, the function is executed in a injection context to allow the usage of `inject`.
PR Close#58518
Before, in a situation like shown in the test, all of the initializers
would be dropped, as the code would try to insert it at the hoisted
property which is going to be deleted.
PR Close#58804
This fixes an issue where the lazy-routes migration would crash for component classes a
decorator without arguments in front of the `@Component` decorator (in particular, it needed
to be the first decorator).
Fixes#58793
PR Close#58796
Adds some logic to the `inject()` migration that allows is to handle parameter declarations with initializers. This was omitted initially, because we don't officially support such cases, but it came up internally.
PR Close#58769
In #57684 the standalone migration was changed so that it replaces any leftover modules with their `exports`, in an attempt to preserve more working code. These changes expand that logic to also cover tests since it's somewhat common internally to only import a component's module without having any references to the component.
Note that tests are a bit of a special case, because we don't have access to the template type checker, so instead we copy over all of the `exports` of that module.
PR Close#58627
Before v19, the default value of the standalone flag was false, this code change flips the logic in the migration to make it true by default.
PR Close#58474
Updates the internal part of the `inject` migration to attempt to correct some cases where the declaration order of properties doesn't match the initialization order.
PR Close#58427
We were filtering out abstract classes pretty late in the migration which led to the internal part of it to make some changes that aren't finalized later. These changes fix the issue by filtering out abstract classes during analysis.
PR Close#58427
With this commit the explicit standalone migration uses the presents of imports to make sure that we can safely remove the standalone prop
and not adding it again when re-run.
PR Close#58418
Fixes that if a class has a `super` call, the `inject` migration would always insert the generated variable before it, even if there's other code before the `super` call.
PR Close#58393
Fixes that when the `inject` migration in internal mode was starting to visit the nodes one level down from the root when considering whether an expression contains local references. This lead it to skip over top-level identifiers and migrate some code incorrectly.
PR Close#58393
Fixes an issue where the `inject` migration was generating and attempting to insert code after a `super` call, but the string buffering implementation was dropping it if the statement right after the `super` call was deleted as a result of the migration.
PR Close#58393
When the internal mode for the `inject` migration is enabled, we find properties without initializers, we add their initializers and we prepend the `inject` calls before them. The remaining properties that couldn't be combined are left in place. This appears to break some internal cases.
These changes work around the issue by hoisting all the non-combined members above the `inject()` calls. This should be safe, because they don't have initializers and as such can't have dependencies.
PR Close#58393
add helper functions provideAppInitializer, provideEnvironmentInitializer & providePlatformInitializer
to respectively simplify and replace the use of APP_INITIALIZER, ENVIRONMENT_INITIALIZER, PLATFORM_INITIALIZER
add a migration for the three initialiers
PR Close#53152
Adds a combined `@angular/core:signals` migration that combines all of the signals-related migrations into one for the apps that want to do it all in one go.
All of the heavy-lifting was already done by the individual migrations, these changes only chain them together for a more convenient developer experience.
PR Close#58259
With this commit, the standalone migration will only migrate code with `standalone: false` to standalone by default (without the standalone attribute)
PR Close#58169
This commit adds an automated `ng generate` schematic/migration for
converting decorator queries to signal queries, as good as possible.
PR Close#58032
This commit promotes the `ExperimentalPendingTasks` service from
experimental to developer preview and includes a migration schematic for
the rename.
BREAKING CHANGE: `ExperimentalPendingTasks` has been renamed to
`PendingTasks`.
PR Close#57533
Dedenting the smallest leading whitespace is useful for conveniently
testing the output of a migration. This commit includes the helper in
Tsurge.
PR Close#57777
With the framework enabling `standalone` by default (making module based an opt-in), the migration will migrate none-standalone existing components and add `standalone: false` to the decorator.
PR Close#57643
Currently during the module pruning stage of the standalone migration we assume that any leftover modules which only have `imports` and `exports` can safely be removed. That can be incorrect for the cases where some parts of the app were converted to standalone outside of the migration.
These changes update the logic so that such modules are replaced with the `exports` which are used within the specific component.
Fixes#51420.
PR Close#57684
Replaces esbuild with Rollup for bundling schematics to support code splitting, as esbuild does not handle code splitting when targeting CommonJS modules.
**Before:**
```
du -sh dist/bin/packages/core/npm_package/schematics
7.7M dist/bin/packages/core/npm_package/schematics
```
**After:**
```
du -sh dist/bin/packages/core/npm_package/schematics
3.1M dist/bin/packages/core/npm_package/schematics
```
PR Close#57602
Updates the migration so that it passes the type as a generic in the case of `@Inject(SOME_TOKEN) foo: SomeType`. This is done for two reasons:
1. It's a fairly common pattern and it ensures that the code can still be compiled.
2. It avoids leaving behind unused imports.
PR Close#57389
Kristiyan Kostadinov