This helper method is simply a convenience function that reduces some
boilerplate with manually adding and removing a task around some
asynchronous function.
PR Close#56546
The query migration will now fully re-use the reference resolution and
migration logic from the input migration to reliably migrate references
to the new signal properties, supporing control flow outsourcing etc.
PR Close#57777
Commonly when testing Tsurge migrations, we need to diff text content of
files. This commit adds a colored diff helper that makes writing tests
much easier.
PR Close#57777
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
This commit introduces an overload for `input` to accept `undefined` as initial value if only
options are needed to be provided, inferring an input of type `T|undefined`. Prior to this change,
the type argument as specified needed to include `|undefined` explicitly even though that isn't
necessary when passing options isn't needed.
Relates to #53909
PR Close#57621
The reference migration code of the signal input migration should be
re-usable as the queries migration needs the exact same.
This builds on top of the shared reference resolution logic from
previous commits. Similarly this commit introduces a small "host" for
providing necessary configurable information about what references
should be migrated; supporting e.g. "input incompatibilities".
This is important as e.g. queries may also be incompatible for migration
and references to such, should not be migrated.
PR Close#57766
Allows us to re-use the reference resolution that works within TS code,
Angular templates, or host bindings. This is helpful for queries
migration which also needs to migrate many references, or allows use in
the output migration.
This is achieved by introducing an abstraction of the "known inputs"
registry we have already, but making it more generic to work with _any_
class fields. Known inputs can then implement/extend this. Queries
similarly.
The "known fields" construct gives insight on field unique IDs etc. This
is then used by the reference resolution to determine if it's a
reference that needs to be captured.
We may move all of this code to Tsurge eventually; depending on how
useful it is. We'll discuss.
PR Close#57766
This change uses the outputToObservable utility function to
convert migrated outputs to Observables. This happens only
in test files as it is a common practice to use RxJS to listen
to events raised by the component under test.
PR Close#57691
Currently several parsing errors in the new control flow (e.g. missing `track` expression) produce errors whose span targets the entire block. This can be really noisy in the IDE where the error can span many lines in the template.
These changes switch to highlighting just the start of the block.
PR Close#57711
Instead of traversing the same paths multiple times, we should avoid
this extra work and optimize. This solves some issues in super large
files with extremely complex flow graphs. E.g. large `ngOnChanges`
functions in Pantheon.
For an example of a flow graph where it doesn't make sense to re-visit
nodes that have multiple incoming edges, see this internal screenshot:
https://screenshot.googleplex.com/6ub4e5e5gbzJAvH
PR Close#57719
Migrations may resolve files in e.g. `blaze-out` and try to compute a
path for the file that is "recognizable" across workers. E.g. in one
worker, it may be the actual `.ts` file inside the source tree, while in
the other, the file may be inside `blaze-out`.
Tsurge currently expects project relative paths to be passed around.
Those project relative paths are currently only based on the single root
directory. Hence paths inside `blaze-out` would actually not be
recognizable.
The fix idea here is that we introduce a structure for Project files.
This structure will contain two fields:
- an ID of a file. This is similar to a module ID in the project. Those
are resolved with respect to all root directories. This matches the
conceptual virtual roots of `tsconfig#rootDirs`. The IDs can be used
for matching files across workers, assuming those are executing using
the same root directories, and handle the same overall project (e.g.
google3).
- a path relative to the primary project root. Multiple roots may be
configured, but the primary project root, is the directory that
contains all others. See: `tsconfig.rootDir`. This path is NOT
necessarily useful for matching files between stages etc, but it's
useful for writing replacements for a given file to disk.
Note that those two things cannot be combind into one conceptual
"project relative path" because a path relative to the most appropriate
root directory cannot be used for safe replacements. E.g. consider a
replacement matches a file from a root directory like `/sub/`. The path
inside `/sub/` would then omit the `/sub/` and later on when writing
replacements, we wouldn't know which root directory it actually was part
of. Hence the concept of a "project root relative path" and the "ID".
ds
PR Close#57677
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
