Adds the migration phase for migrating inputs and references. Thise
phase may execute as the third step when batching.
The migration is intentionally split into three phases:
1. Extract and analyze
2. Inheritance merge / merge of metadata
3. Migrate
This allows us to batch the migration in Google3, or for large projects,
merge metadata, and then batch-execute migration for computation of
replacements. This is compatible with Google's LSC tsunami tool.
PR Close#57082
E.g. detects `spyOn(myComp, 'input')`. This is problematic
as `input` no longer provides access to the raw value via property
access, but via a getter. The `spyOn` would be effictively a noop,
causing tests to fail. We skip such inputs for safety right now.
Similarly, we have an advisor for correcting type safety loss
with `.componentInstance` in unit tests. This is a common pattern
but is typed in Angular core as `any`. This breaks resolution of
references and we accidentally miss those. This advisor mitigates that.
PR Close#57082
This commit adds the logic for detecting and capturing references to
Angular `@Input`s. Those references may be migrated to unwrap signals
as part of the migration; or are refactored into temporary variables.
This commit detects and captures:
- host bindings references
- template references
- TypeScript references
PR Close#57082
This commit adds logic for AST traversing Angular HTML templates and
detecting references to Angular `@Input`s that may be migrated.
In addition, the expression visitor logic is built in a generic way so
that it can also be used for finding references in host binding
expressions— where no type check block information is available.
PR Close#57082
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
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
This fixes the case that common module is removed on a second run of the migration. We were not looking at block parameters for common module usage.
PR Close#56968
Before this commit, the migration was removing the `AfterRenderPhase` enum from the imports but not the comma, resulting in invalid code:
ts
```
import { , Directive, afterRender } from '@angular/core';
```
This commit fixes this by using `updateNamedImports` and `replaceNode` instead of `removeNode`.
After:
ts
```
import { Directive, afterRender } from '@angular/core';
```
PR Close#56524
Adds an `ng update` migration to move users from using the phase flag
with `afterRender` / `afterNextRender` to passing a spec object instead.
PR Close#55648
This is related to an issue that was reported internally. We were assuming that `hasNgModuleMetadataElements` will return true only for property assignments initialized to arrays, but that's not the case.
These changes update the type and our assertions to more accurately reflect the AST and to avoid the error.
PR Close#56302
Introduces a new `LetDeclaration` into the Render3 AST, simiarly to the HTML AST, and adds an initial integration into the various visitors.
PR Close#55848
empty ngSwitchCase generate `case ()` which isn't valid syntax therefore adding quotes will help prevent us migrate empty case if no condition was provided
fix angular#56030
PR Close#56105
The migration was breaking tests with test modules that imported `HttpClientTestingModule`,
as it removed the JS imports without migrating the module imports.
The migration now handles the case where `HttpClientTestingModule` is used in test modules,
by replacing the module import with the `provideHttpClient` and `provideHttpClientTesting` providers.
Before:
```ts
import { HttpClientTestingModule } from '@angular/common/http/testing';
@NgModule({
declarations: [AppComponent],
imports: [HttpClientTestingModule],
})
export class TestModule {}
```
After:
```ts
import { provideHttpClientTesting } from '@angular/common/http/testing';
import { provideHttpClient, withInterceptorsFromDi } from '@angular/common/http';
@NgModule({
declarations: [AppComponent],
imports: [],
providers: [provideHttpClient(withInterceptorsFromDi()), provideHttpClientTesting()]
})
export class TestModule {}
```
PR Close#55803
The `HttpClientModule` migration was dropping the existing properties other than imports and providers when updating an `@NgModule`, `@Component` or `configureTestingModule`.
PR Close#55777
This commit handles two cases that were breaking applications when using the new migration:
- tests using `HttpClientModule` in `TestBed.configureTestingModule` were broken as the import was removed, but the module is still present in the test configuration. It now properly adds `provideHttpClient(withInterceptorsFromDi())` and related imports to the test.
- tests using `HttpClientTestingModule` were migrated to use `provideHttpClient(withInterceptorsFromDi())` but the necessary imports were not added. They are now added by the migration.
PR Close#55640
Fixes several issues with the `HttpClient` migration that showed up after I tried updating the Material docs site to the latest v18 release. Includes:
* The migration was assuming that all Angular decorators have at least one argument. This led to a null pointer error that broke the v18 update process when I was testing it.
* The migration incorrectly reimplemented the detection of classes with Angular decorators. This can cause code to be migrated incorrectly and doesn't handle cases like import aliases. I've switched it to use the existing tooling for detecting decorated classes.
* The migration was trying to migrate directives, even though they don't support the `imports` field.
* The migration was detecting `TestBed.configureTestingModule` calls using a raw string match which is very fragile and can be broken by the user's formatting.
* There were syntax errors in the unit tests.
* There were type checking errors in the unit tests, for example none of them were importing the Angular decorators that they were migrating.
There's more room for improvement, but this should resolve the most glaring issues without having to rewrite too much.
PR Close#55557
This migration will allow developers to migrate the deprecated `HttpClientModule`, `HttpClientJsonpModule` & `HttpClientXsrfModule` to their respective provider functions.
PR Close#54020
This commit removes of migrations introduced in version 17, along with the relocation of a migration from 17.3 to version 18. This ensures that this is ran for users who may have updated from one minor to another without executing `ng update`
PR Close#55391
Two-way bindings are meant to represent a property binding to an input and an event binding to an output, e.g. `[(ngModel)]="foo"` represents `[ngModel]="foo" (ngModelChange)="foo = $event"`. Previously due to a quirk in the template parser, we accidentally supported unassignable expressions in two-way bindings.
In #54154 the quirk was fixed, but we kept support or some common expression because of internal usages. Now the internal usages have been cleaned up so the backwards-compatibility code can be deleted.
Externally a migration was added in #54630 that will automatically fix any places that depended on the old behavior.
BREAKING CHANGE:
Angular only supports writable expressions inside of two-way bindings.
PR Close#55342
The control flow migration was using a couple of Greek letters as placeholders. This ended up conflicting with templates authored in Greek.
These changes use a more obscure placeholder to make conflicts less likely. It also moves the placeholder generation to a centralized function so it's easier to make changes if we decide to update the pattern again.
Fixes#55085.
PR Close#55113
Fixes that the control flow migration was throwing an error if the `imports` of a component are initialized to an identifier.
Fixes#55080.
PR Close#55081
As a part of #54154, an old parser behavior came up where two-way bindings were parsed by appending `= $event` to the event side. This was problematic, because it allowed some non-writable expressions to be passed into two-way bindings.
These changes introduce a migration that will change the two-way bindings into two separate input/output bindings that represent the old behavior so that in a future version we can throw a parser error for the invalid expressions.
```ts
// Before
@Component({
template: `<input [(ngModel)]="a && b"/>`
})
export class MyComp {}
// After
@Component({
template: `<input [ngModel]="a && b" (ngModelChange)="a && (b = $event)"/>`
})
export class MyComp {}
```
PR Close#54630
Fixes an edge case where a single-line elemnt with a long tag name a closing bracket on a new line was putting the control flow migration into an infinite loop.
Fixes#54587.
PR Close#54588
In rare cases people may use an underscore in their component names, which was not accounted for in the formatting portion of the migration.
fixes: #54532
PR Close#54533
Adds some logic to skip over `TestBed.configureTestingModule` calls where the `declarations` aren't initialized to an array. We can't migrate these cases, because test migrations don't have access to the Angular compiler. Previously the migration would throw a runtime error.
PR Close#54122
This addresses the offset issue caused when a switch case was empty with no spaces or children being affected by the markers that were added, but not accounted for in offset. The markers are not needed for empty content and can be safely removed in this case.
fixes: #53779
PR Close#53839
The formatting that would preserve attribute indents completely missed attributes that start on new lines rather than the same line as the opening element.
PR Close#53636
In cases where CommonModule was unsafe to remove but other imports were present, the symbol check would be skipped. This should run for all the possibly removed symbols for safety.
PR Close#53637
During formatting, attribute indentation is changed, and that can affect internationalized strings. This fix detects if an attribute value string is left open and skips formatting on those lines.
PR Close#53625
This addresses the case where modules are being used and declared in the same file as the component. It is unclear whether its safe to remove the common module in this case, so best to leave it.
PR Close#53575
Internationalization is whitespace sensitive. This change updates the formatting code to process for i18n attributes and prevent reformatting those sections of the template.
PR Close#53538
This fix handles the common case where an ngswitch might have invalid syntax post migration. This is likely due to using elements other than case or default underneath the ngswitchcase. This will fail out of the migration for that file when these cases are detected with a useful console message.
fixes: #53234
PR Close#53530
Paul Gschwendtner