This commit includes the initial logic for converting `@Input()` to
`input`. The logic is not fully polished in terms of what use-cases
and patterns we want to generate, but it's working pretty stable
with testing in Angular Material and some g3 targets.
We may improve this and e.g. generate the `input()` shorthand in a
couple of cases.
The commit also includes some related helpers/parts that are needed
for the migration phases.
Notably the conversion phase is split up into preparation and migration.
That is necessary because as part of analysing we already try to
prepare to see if it's "possible". This is necessary for the global
metadata analysis, so that we can know that certain references are
incompatible across compilation units (e.g. when running as a batch).
PR Close#57082
This commit adds the initial set of helpers and registries for tracking
inputs discovered in the signal input migration.
A few short summary notes:
- Every input has an unique key. This key is used for global analysis
that may be performed when the migration is executed on a per
individual unit basis in Google3 via e.g. go/tsunami — The keys allow
us to build a combined global metadata for e.g. references or figuring
out which inputs are incompatible or not.
- A known input may be _any_ input in an compilation unit/ the program.
E.g. even inputs from `d.ts`. We keep track of these inputs so that we
can later figure out if a reference `ts.Identifier` points to any of
those. In addition it allows us to attach incompatibility metadata to
those. I.e. incompatible for migration because "something writes to
the input".
PR Close#57082
This commit introduces the initial flow analysis logic for the input
migration. The flow analysis will allow us to determine which references
inside a flow container participate potentially in narrowing.
We can then use this information and the proposed restructred accesses
to refactor the accesses to use temporary variables where needed. E.g.
```
if (this.input) {
this.input.charAt(0);
}
```
```
const input_1 = this.input();
if (input_1) {
input_1.charAt(0);
}
```
Notably we could easily, naively figure out similar references in a flow
container and always use temporary variables, but this approach allows
us to minimally introduce such variables and this commonly leaves code
very readable when no narrowing was involved (noticable in g3 tests)
E.g. simple cases like:
```
this.input.bla();
this.input.bla();
```
would otherwise result in refactored expressions, leveraging a temporary
variable.
PR Close#57082
This allows use of poisoned data for migrations. Right now, migrations
often enable this flag by creating some deeper structures of the
Angular compiler, but with this change it's easier to enable as a
private compiler option.
This is helpful for migrations, specifically the signal input migration
as it allows us to generate as much TCB code as possible, for reference
resolution.
PR Close#57082
This commit exposes metadata about inputs that are defined inside
the `inputs` field of `@Directive` or `@Component` class decorators
This is useful and necessary information for migrations, like the
signal inputs migration.
PR Close#57082
This option was introduced out of caution as a way for developers to opt out of the new behavior in v18 which schedule change detection for the above events when they occur outside the Zone. After monitoring the results post-release, we have determined that this feature is working as desired and do not believe it should ever be disabled by setting this option to `true`.
PR Close#57029
Adds a new extended diagnostic that will flag `@let` declarations that aren't used within the template. The diagnostic can be turned off through the `extendedDiagnostics` compiler option.
PR Close#57033
Adds the new `ng generate @angular/core:inject-migration` schematic that will convert existing code from constructor-based injection to injection using the `inject` function. The migration also has a few options that should help reduce compilation errors.
This migration is slightly different than our usual ones in that it may have to update entire class or constructor declarations. We don't go through the `ts.factory.update*` APIs for this, because it can cause the entire declaration to be re-formatted. Instead, this migration tries to insert strings in a way that won't affect the user's formatting.
PR Close#57056
Some Angular template instructions that follow each other may be chained
together in a single expressions statement, containing a deeply nested
AST of call expressions. The number of chained instructions wasn't previously
limited, so this could result in very deep ASTs that cause stack overflow
errors during TypeScript emit.
This commit introduces a limit to the number of chained instructions to
avoid these problems.
Closes#57066
PR Close#57069
There are existing usages that inject the renderer to manualy listen (often for event
delegation purposes). These should contribute as well.
PR Close#56799
Adds a new extended diagnostic that will flag `@let` declarations that aren't used within the template. The diagnostic can be turned off through the `extendedDiagnostics` compiler option.
PR Close#57033
The `Timeout` object in Node.js has a `refresh` method, used to restart `setTimeout`/`setInterval` timers. Before this commit, `Timeout.refresh` was not handled, leading to memory leaks when using `fetch` in Node.js. This issue arose because `undici` (the Node.js fetch implementation) uses a refreshed `setTimeout` for cleanup operations.
For reference, see: 1dff4fd9b1/lib/util/timers.js (L45)Fixes: #56586
PR Close#56852
The `window` global is patched by domino on the server but the value of `window.location.href` isn't a valid base.
Before this change `getUrl()` would throw when running in devmode on the server.
Fixes#56207
PR Close#56213
Fixes that only the first callback was firing when multiple are registered in the same call to `afterNextRender`, e.g. `afterNextRender({earlyRead: fn, read: fn});`
Fixes#56979.
PR Close#56981
This is a performance optimization that would exit early when
code actions are requested, but we know Angular cannot provide fixes
based on the error codes.
Previously, we would unnecessarily compute and analyze the application
for semantic diagnostics.
This will be helpful for: https://github.com/angular/vscode-ng-language-service/pull/2050
PR Close#57000
Fixes that the runtime implementation of `ɵɵngDeclareDirective` was interpreting the `hostDirectives` mapping incorrectly. Instead of treating the inputs/outputs as `['binding', 'alias']` arrays, it was parsing them as `['binding: alias']`. This was leading to runtime errors if a user is consuming a partially-compiled library in JIT mode.
Fixes#54096.
PR Close#57002
