Only touch tsconfig files for targets that use an Angular builder, including community ones like Nx, so non-Angular projects in mixed workspaces are left alone.
Fixes#69837
We keep getting PRs that target single usages of `hasOwnProperty` and we have ~100 of them. These changes aim to address the issue centrally by swapping out all the instances and adding a lint rule against introducing new ones.
Currently, signal migration schematics in best effort mode doesn't do a very good job migrating input writes when there is a nested property access in templates.
In event handlers, no attempt is made to migrate a nested access in the left-hand-side of assignments or anything in their right-hand-side. E.g., nothing will happen here:
`(ngModelChange)="inputD.prop = $event + inputF"`.
Additionally, when a migration attempt is made, parentheses are often incorrectly placed on the parent, both in event handlers and two-way bindings:
`(ngModelChange)="inputC = $event"` is migrated to `(ngModelChange)="inputC = $event()"`.
`[(ngModel)]="inputB.prop.prop"` is migrated to `[(ngModel)]="inputB.prop().prop"`.
The following:
`@Output() someChange = new EventEmitter<void>();`
is correctly migrated to:
`readonly someChange = output<void>();`
However, a TODO is incorrectly inserted for subsequent emissions from
`someChange`, stating that an argument is expected.
Currently if a `@for` loop doesn't have a `track` expression we don't produce an AST for it at all which means no type checking and language service support for it.
These changes make it so we produce the AST anyways since it gives the user more tools to resolve the issue (e.g. autocompletion when writing the `track` expression).
Removes the @angular/compiler import from the safe optional chaining migration. This import is not needed as the compiler package import is side-effectful and has no functional use here.
This migration ensure that existing code is wrapped by the `$safeNavigationMigration` magic function when necessary to maintain the pre-exisiting behavior of exisiting optional chaining expressions.
becomes input + linkedSignal
When a component has both a model() property and a conflicting output property (e.g., foo model + fooChange output), this migration converts the model() to an input() + linkedSignal() pattern to avoid naming conflicts.
Fixes#67340
This commit updates provideClientHydration to automatically enable incremental hydration by default. It also introduces a new withNoIncrementalHydration feature for opting out, adds conflict safety checks, and includes a schematic migration.
This updates the SymbolBuilder to no longer use ts.TypeChecker internally to
build symbols for the language service. These lookups are deferred/done later
using the newly expanded template type checker API.
Currently the migration that add `ChangeDetectionStrategy.Eager` to components tries to add the properties as last in the object literal. This can be tricky, because TS doesn't reflect the commas in the AST so we need have to do brittle string lookups to know where to insert it.
These changes switch to inserting the property before the last pre-existing property which should be a bit more robust.
Exisiting applications will be migrated to keep using the XHR backend to prevent any breaking changes. `withXhr()` is to the `provideHttpClient` provider function.
In v22, `OnPush` becomes the default strategy. To maintain the ChangeDetection behavior of exisiting apps, components without an explicit change detectino strategy will get `Eager` assigned.
The common-to-standalone migration did not check for existing imports
when adding needed imports after removing CommonModule. This change adds deduplication
logic to filter out imports that already exist in the imports array
before adding them, ensuring each import appears only once.
Back in #39323, I added a new `ThisReceiver` node to represent accesses done through `this` and I ended up making it inherit from `ImplicitReceiver`. The logic was that in most cases accessing through `this` was the same as the implicit access.
Over the years this has proven to not be a great idea, because no other AST nodes do this and one has to keep it in mind whenever dealing with `ImplicitReceiver`.
These changes remove the inheritance and update all of the usage sites accordingly.
the common-to-standalone migration only matched [ngTemplateOutlet] and
[ngComponentOutlet] bindings and missed their structural forms
(*ngTemplateOutlet and *ngComponentOutlet). This caused missing imports
when removing CommonModule. This change adds structural directive
patterns so the migration correctly identifies needed imports.
In https://github.com/angular/angular/pull/64745, a fix was introduced for templates referenced with a trailing semicolon. However, templates are still incorrectly removed when there are whitespace characters before the template name.
This commit updates the control flow migration logic to ensure templates referenced with preceding whitespace are not removed.
Fixes#64854
This commit fixes a behavior where under certain conditions, the migration script ignored
a template reference with a trailing semicolon and incorrectly removed the definition
of a referenced template.
Fixes#64741
Introduces a migration that replaces CommonModule usage with individual imports from @angular/common, aligning with Angular's standalone component approach and improving module import clarity
PR Close#64138
When the migration command was run for inputs, if the input had more than one reference in a method the migration would generate incorrect code
Fixes#63018
PR Close#64367
Now that the control flow migration is running as a part of `ng update`, we need to be a bit forgiving about there not being any matching files since it can break the entire update process.
These changes switch the error to a warning and it counts the files for the entire workspace, not the individual projects.
PR Close#64253
Prevents migration of @input() properties that contain references to 'this' in their initializer functions. This ensures that functions accessing class members via 'this' remain unchanged, preventing potential build errors.
PR Close#64142
lazerg