Migrates `packages/core/schematics` to `ts_project`. As part of this,
this commit cleans up some of the mixed module types and tsconfigs in
the folder. A single tsconfig (and it's test variant) are now used.
For the shipped schematics, we explicitly use the `.cjs` extension, so
that the bundles are properly recognized as CommonJS; even if they are
part of the `type: module` `@angular/core` package.
The `package.json` with `type: commonjs` is removed from
`packages/core/schematics` as it's no longer needed given the explicit
extension & caused issues as schematics are compiled with ESM but are
only later bundled for shipping & some tests as ESM.
PR Close#61420
This commit changes Tsurge's operation within angular-devkit (i.e. the CLI) to
no longer retain all programs across all migrations. This isn't necessary for
so-called "funnel" migrations so not retaining the programs for those migrations
is a pure performance win. The "complex" migrations may see increased execution time
given that the program is now being recreated for the actual migration phase to run,
although reduced memory pressure may help alleviate this overhead. Since this new
approach should help prevent Node from running out of memory and failing entirely
this is preferred over a potentially increased execution time.
Fixes#59813
PR Close#60776
Currently when we reuse a Tsurge migration is reused externally, there's some glue code that needs to be executed in a specific order. The code gets copied between the different migrations which is error-prone and means that bugs may have to be fixed several times.
These changes move the common steps out into a separate function so that only the migration-specific logic (mostly instantiation and logging) is left in the schematic.
PR Close#60386
PR Close#60776
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
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 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
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 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
The Angular CLI devkit and Tsurge, as well as TypeScript only deal with
Posix paths. We also normalize paths into posix paths, and try to
implement a devkit compatible virtual file system for the compiler-cli.
This commit fixes an issue where we accidentally resolved `/` to the
system root on Windows. e.g. `C:/`. This broke the posix and devkit
paths throughout tsconfig parsing.
This commit fixes this.
Fixes#58132.
PR Close#58137
This allows us to return extra properties along with `#migrate`
replacements. Useful for language service integration or other
integrations of Tsurge migrations in special runners.
PR Close#58106
We should support tracking statistics in Tsurge migrations. This allows
us to print them after migration, or run migrations periodically as
large scale changes to track to progress.
TODO is an internal implementation that eventually runs periodcally
in LSC modes.
PR Close#58019
If we see a reference to e.g. `QueryList#changes`, we should skip
migration to be on the safe side. Similar for other fields of query
lists.
PR Close#57992
Instead of printing the full diff, which may be a super large file or
golden, we only print context around lines with diff. This makes the
diffs much more actionable and readable.
PR Close#57961
When running a migration, tsurge creates a TS program from the tsconfig files found.
This can result in a 18003 error when no files are found (based on the includes/files of the config).
For example, the signal input migration throws in a CLI project that has no spec files:
```
ng g @angular/core:signal-inputs --defaults
Tsconfig could not be parsed or is invalid:
No inputs were found in config file '/tsconfig.spec.json'. Specified 'include' paths were '["src/**/*.spec.ts","src/**/*.d.ts"]' and 'exclude' paths were '["/out-tsc/spec"]'.
```
A similar issue has already been raised in the CDK migration (see https://github.com/angular/components/issues/27055).
This was solved in the CDK (credits to @crisbeto) by ignoring the 18003 error (see 9c1112d408361a47c98dfd470b8e990cbd1753db).
This PR does the same in tsurge.
PR Close#57899
The compiler and its file system implementation expects `fs.exists` to
return `true` even for directories. This caused issues with the TSConfig
resolution as `/` was looked up.
We fix this by making use of `stat` which is equally expensive to
`tree.exists`. The devkit tree's don't expose directory existance checks
out of the box.
Fixes#57887.
PR Close#57897
Optional operations that don't run in the actual application compilation
would then cause fatal diagnostic errors breaking the compiler
initialization at runtime.
We should try to keep the migration as close as possible to the
application build.
PR Close#57835
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
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
Currently the import manager always add a space after the import clause
brace. We should only do this if the existing import did the same.
PR Close#57672
Currently whenever we apply the import manager changes in migations, we
leave the decision of multi-line or single-line to the TS printer.
This works, but in practice can cause signficiant file jumps/changes if
there are large imports that aren't wrapped for example, or the other
way around. We should try to be minimal here and preserve the existing
formatting, assuming that a multi-line import remains multi-line, while
a single-line import remains single-line if it already had many items in
a single line, intentionally.
PR Close#57672
This commit shares the logic for looking up a property access, using
`ts.Type` information. This is helpful in case where no linked TS
symbols are available; e.g. templates in test files without TCB.
This helper will be useful for handling object expansion in the signal
input migration; resolving references like `const {x} = this`.
PR Close#57645
Sometimes `--strictPropertyInitialization` is not enabled, while strict
null checks is enabled. In those cases, `undefined` cannot be used as
initial value with `input()`, nor can we expand the type of the input.
We can migrate those instances to `undefined!` to preserve the original
semantics and behavior. In addition, in the future we may leave a TODO
or we may consider skipping migration of such inputs.
PR Close#57629
This allows for the replacements to be conveniently passed between
migration stages. This is especially relevant in 1P where stages may
have different root directories.
Tsunami attempts to relativize paths in general, similar to how we do
here, but this doesn't work with e.g. Funnel-based migrations where
replacements are serialized in between stages; and where the migration
stage at the end doesn't know about the previous root directory anymore.
PR Close#57584
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
(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
Adds initial migration logic to convert decorator query declarations to
signal queries.
We will re-use more part of the signal input migration in follow-ups, to
properly migrate, and e.g. even handle control flow
PR Close#57556
