The visitor that all extended diagnostics are based on hadn't implemented the `visitIcu` method which meant that it wasn't detecting any code inside of them.
Fixes#57838.
PR Close#57845
Notably the inheritance checking is less complete as the one in the
input migration. That is because we can't efficiently determine query
fields in the analyze phase of compilation units. Unless we aggresively
consider every field of decorated classes as queries and complexify
the merged metadata significantly, we can't reliably check for cases
where a class is incompatible for migration because it overrides a
member from a class that is in a different compilation unit.
This is an acceptable limitation though (maybe for now), as worst case,
we would migrate the class and the other compilation unit would simply
break. Not ideal, but migrations are impossible to be 100% correct in
general— so not a surprise.
In the future, we may find ways to identify queries more reliably in
analyze phase already. e.g. if the compiler were to include this
metadata in the `.d.ts`, or if we decide to simply add this to the
metadata, accepting potential significant HDD increase.
PR Close#57854
Before this commit, `@let` decleration with an array where mistaken for a component in the lView and throwing an unexpected error.
This commit fixes this.
PR Close#57816
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
This commit prepares us for sharing the problematic pattern detection,
or inheritance checking. E.g. if a class is manually instantiated, using
certain APIs may not be considered safe. This logic will be shared in
the following commit.
PR Close#57835
Finalizes compiler implementation of the new `hydrate` triggers by:
* Reworking the logic that was depending on the `hydrateSpan` to distinguish hydrate triggers from non-hydrate triggers.
* Fixing that the `hydrate when` trigger didn't have a `hydrateSpan`.
* Adding an error if a parameter is passed into a `hydrate` trigger.
* Add an error if other `hydrate` triggers are used with `hydrate never`.
* Replacing the `prefetch` and `hydrate` flags in the template pipeline with a `modifiers` field.
* Fixing an error that was being thrown when reifying `hydrate` triggers in the pipeline.
* Adding quick info support for the `hydrate` keyword in the language service.
* Adding some tests for the new logic.
PR Close#57831
Introduces a new `ng generate` schematic for migration `@Input()`
declarations to signal inputs.
This migration is the same that is also integrated into the
VSCode extension.
Note: In a follow-up the documentation for this will be improved, and a
flag to report reasons on why certain inputs weren't migrated, is added.
PR Close#57805
Whenever the `ngc` binary is used directly to parse configurations, we
should try to respect the configured file system like we do in all other
places. Right now one spot where we escape the FS is for reading
directories to e.g. support tsconfig#includes.
This commit fixes this, implementing TypeScript's read directory method
leveraging the configured FS. The approach taken here was used for a
couple of months/years for Angular Material migrations and no issues
were found.
PR Close#57805
For component stylesheet hot module replacement scenarios, it will be necessarily to directly
encapsulate a component's stylesheet in a single operation. This currently requires the
consumer of the `encapsulateStyle` helper to use the internal Angular attribute values combined
with a find/replace over the entire stylesheet. To avoid both of these, the helper function now
has an optional second parameter which allows direct and full encapsulation of a style for a given
component when the component identifier is known.
PR Close#57809
This commit marks the input, output and model APIs as stable
(along with the associated APIs) and thus exits the dev preview
phase for those APIs.
PR Close#57804
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
Add a check to the language service that ignores specified diagnostic codes. This will be useful in g3.
The codes to ignore are exposed as part of the PluginConfig.
Fixes github.com/angular/vscode-ng-language-service/issues/1243
PR Close#57675
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
Whenever the signal input migration runs in VSCode, other inputs are
marked as incompatible via the config. Best effort mode currently skips
those incompatibilities and still migrates them. This is incorrect as
the config intends to skip those inputs, regardless of best effort mode.
PR Close#57672
The migration took a type from the directive handler metadata, and
inserted it into a synthetic node for the new input() call. This works
perfectly fine, but in some cases, I saw some `T:VAE` comments attached
🤯 These are from the type checker which attached
synthetic comments to the exact same node.
PR Close#57672
Whenever we migrate object expansion patterns, we may need a temporary
variable to generate a construct like:
```ts
const {bla: blaValue} = this;
const bla = blaValue();
```
We should instead use `blaInput` as the name for the temporary
variable. For narrowing constants, `blaValue` is correct, but here
it's an actual reference to the input / signal.
PR Close#57659
With the preparation work from previous commits, we are able to reduce
analysis time of the migration from e.g. whole Material repo 7seconds to
0.1seconds when the migration is invoked via the VSCode extension.
This is possible because we can avoid many expensive type checking
lookups if we know what inputs are actually migrated. We do this by
adding some naive pre-check to see if identifiers are possibly pointing
to a migrated input.
This is possible now because we no longer migrate aliased identifiers
for object expansion, but instead migrate directly at object
expansion declaration. This allows us to assume that all possible
references to inputs must go through identifiers that are named like
the original input class field name.
PR Close#57659
Instead of printing the enum name as the reason why migration did not
complete, we should print some human-readable descriptions.
This commit implements this. This logic may also be useful for the
devkit comment generation, or CLI usage.
In addition, we expose another VSCode refactoring to try via best effort
mode. There is no way for prompting, or adding multiple actions for the
same refactoring, so we expose a new refactoring.
PR Close#57659
Kristiyan Kostadinov