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
This ensures the migration works for these TypeScript versions. The
migration is very sensitive to the TS version and its internals; so it
makes sense to test all of these.
PR Close#59463
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
Skips the TS version check in tsurge since it's blocking some internal changes and generally isn't necessary since the app will be checked when it's built anyways.
PR Close#58866
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
Fixes#58630
```html
<button (click)="someSubject.next()">Click</button>
```
was migrated to an `.emit` call, even if `someSubject` was not an `EventEmitter`.
The issue was the same in host listeners.
PR Close#58631
A dot was appearing in the middle of the comment for `DerivedIsIncompatible`.
While at it, a dot was missing in `ClassManuallyInstantiated`.
PR Close#58636
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
Running `ng g @angular/core:signals` prompts for the question on which migration to run and offers 3 options (inputs, outputs, queries).
Running with `--defaults` skips the prompts, but only runs 2 of them.
This fixes it by including the `outputs` migration in the default ones.
PR Close#58635
This commit improves the temporary variable generation in signal
migrations, whenever references are "shared" inside property
declarations.
PR Close#58581
Currently whenever we would come across a code snippet like this, where
`maxCellsPerRow` is an input, the control flow analysis would fall apart
because the first occurence of the node points to a control flow node
that is offset-wise "after" the first occurence. This commit makes the
logic more robust.
PR Close#58581
Previously we always ran Tsurge migrations with an Angular program, even
if it's a plain `ts_library` target. This has changed now, so we also
need to properly handle the case where a `ts_library` is analyzed, but
no Angular program is available.
PR Close#58541
Tsurge can run against the full Google3 depot, and will often also deal
with plain `ts_library` targets. Those shouldn't be constructed with the
Angular compiler as this could cause out of memory breakages etc. The
targets are simply not "proven" to be compatible with the Angular
compiler; so we shouldn't use them when not necessary.
PR Close#58541
We were not properly passing around the TCB full program optimization,
so TCB generation was done per individual file. This significantly
slowed down reference resolution.
PR Close#58525
The use of relative imports vs. module imports and the existing mismatch
can cause symbols to be duplicated in migrations. This is problematic as
it breaks migration logic or compiler logic in the worst case.
Long-term we will solve this by having a better Bazel toolchain where
both relative and module imports can point to the same files; but in
practice this is not the case right now.
This commit fixes the fallback template logic in the signal
input/queries migration; in case no type check block information is
available.
PR Close#58515
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 repeating the logic that deletes a node together with all its comments in a few different places. These changes consolidate the logic under `ChangeTracker.removeNode`.
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
Before this fix the output migration was incorrectly assuming
that the @Output decorator takes its params as an object.
What happens in reality is that the @Output decorator is taking
alias as the only argument, without any object literal wrapper.
PR Close#58411
This change fixes a bug where the output migration was interacting
with the InputManager utility in the way that was resulting in
incorrect import replacements.
The fix consists of making sure that a new ImportManager instance
is created for each and every file containing @Output declarations.
PR Close#58414
In 1P, we saw that a type of a target wasn't resolvable, referenced in a
`hostBindings#directive` field. This breaks the entire pipeline; so we
should handle gracefully but report an error.
Worst case scenario here is that we would miss some references to the
given directive/component. This is acceptable and we can continue
investigation why that given target was broken; especially since the
file was part of the target inputs- but seemingly not in the `tsconfig`.
PR Close#58413
Fixes that the migrations weren't properly determing the highest block
of multiple shared references. The logic was flawed by checking the
`start` indices; because we also need to respect that the blocks
should enclose all references; and the block practically is a common
ancestor. This is not guaranteed without this commit.
Note: The logic assumes that all references are part of the same control
flow container; this is verified.
PR Close#58413
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
This is necessary given the previous Tsurge refactorings. It should
speed up migrations in the merge phase signficiantly and reduce memory
pressure. In 1P, we already have workers from analyze phase anyway— so
those can be re-used for parallel metadata merging.
PR Close#58280
This is helpful and important for large scale migrations where a single
call for merging _all_ unit data's can be subject to memory / disk
resource constraints. Consider a compilation unit data for every target
in Google3, and those being merged in a single program.
PR Close#58280
This change captures different statistics from the run of the
output migration:
- total number of outputs detected
- number of problematic outputs that can't be migrated
- overall success rate
PR Close#58321
Paul Gschwendtner