#51891 introduces a new syntax that assigns a new meaning to the `@` and `}` in Angular templates. This is problematic for existing apps which may have the characters in their templates already, because it can lead to syntax errors.
These changes add an `ng update` schematic that will replace any usages of the special characters with their HTML entities.
PR Close#51905
The class-based guard and resolver interfaces are deprecated. The
`Router` types only support functional guards definitions. Classes can
still be used as the underlying implementation of functional guards and
resolvers but there will not be an interface requiring a specific structure
for those classes.
There are also helper functions like `mapToCanActivate` that allow
converting the existing class-based guards directly to functional guards
at the route definition. This will be done in a separate migration.
PR Close#49337
Implements a new `ng generate @angular/core:standalone` schematic that allows the user to convert all the declarations in a set of NgModules to standalone.
PR Close#48790
This is basically a pre-step for combining devmode and prodmode into a
single compilation. We are already achieving this now, and can claim
with confidence that we reduced possible actions by half. This is
especially important now that prodmode is used more often, but rules
potentially still using the devmode ESM sources. We can avoid double
compilations (which existed before the whole ESM migration too!).
We will measure this more when we have more concrete documentation
of the changes & a better planning document.
Changes:
* ts_library will no longer generate devmode `d.ts`. Definitions are
generated as part of prodmode. That way only prodmode can be exposed
via providers.
* applied the same to `ng_module`.
* updates migrations to bundle because *everything* using `ts_library`
is now ESM. This is actually also useful in the future if
schematics rely on e.g. the compiler.
* updates schematics for localize to also bundle. similar reason as
above.
PR Close#48521
The Angular CLI does not yet support schematics running as ESM. For
this reason we switch the schematics BUILD targets to explicitly
use ESM (as an exception in the repo).
PR Close#48521
These migrations can no longer run due to a single update version policy (IE: from 13 to 14, 14 to 15 etc..). Therefore these are redundant and can be deleted.
We also remove the `-beta` suffix from the version which is not needed as the Angular CLI will add the prerelease suffixes automatically.
PR Close#48414
As of Angular v15, the deprecated `relativeLinkResolution` config option of the Router is removed. This migration cleans up (removes) the `relativeLinkResolution` fields from the Router config objects in applications code.
```ts
import { RouterModule } from '@angular/router';
RouterModule.forRoot([], {
relativeLinkResolution: 'legacy',
enableTracing: false,
});
```
```ts
import { RouterModule } from '@angular/router';
RouterModule.forRoot([], {
// the `relativeLinkResolution` is removed
enableTracing: false,
});
```
PR Close#47604
Since Angular v15, the `RouterLink` contains the logic of the `RouterLinkWithHref` directive and now developers can always import and use the `RouterLink` directive when they need to add a `[routerLink]` in templates. This migration finds all imports and usages of the `RouterLinkWithHref` class and rewrites them to `RouterLink` instead.
```ts
import { RouterLinkWithHref } from '@angular/router';
@Component({
standalone: true,
template: `<a [routerLink]="'/abc'">`,
imports: [RouterLinkWithHref]
})
export class MyComponent {
@ViewChild(RouterLinkWithHref) aLink!: RouterLinkWithHref;
}
```
```ts
import { RouterLink } from '@angular/router';
@Component({
standalone: true,
template: `<a [routerLink]="'/abc'">`,
imports: [RouterLink]
})
export class MyComponent {
@ViewChild(RouterLink) aLink!: RouterLink;
}
```
PR Close#47599
Places that use `pathMatch` need an explicit `Route` or `Routes` type on
the variable so TypeScript does not infer the type as just 'string'.
PR Close#45084
When using `ng update` users cannot update multiple major versions at the same time. Therefore migrations that are not targeting version 14 cannot be run and therefore we are removing them.
PR Close#44857
This migration will insert `<AnyForUntypedForms>` or `<AnyForUntypedForms[]>` at existing uses of `AbstractControl` classes, as well as calls to `FormBuilder` methods.
We need to submit this ahead of time in order to get started with the migration in google3.
PR Close#44449
These tests had been disabled when we initially disabled ViewEngine.
The tests appear to run fine despite this, so we can re-enable them.
PR Close#44013
With this change we remove no longer needed migrations. These migrations are no longer accessible following a change angular/angular-cli#21986 in the Angular CLI. The CLI now shows an error message when users try to update `@angular/` and `@nguniversal/` packages across multiple major versions.
Example to update from version 11 to version 13 the recommand approach is to run the following commands
```
ng update @angular/core@12
ng update @angular/core@13 (which is the same as ng update @angular/core)
```
NB: It is recommand that when update from one major to another, users verify that their applications is working as expected.
PR Close#43947
With this change we remove no longer needed migrations. These migrations are no longer accessible following a change https://github.com/angular/angular-cli/pull/21986 in the Angular CLI. The CLI now shows an error message when users try to update `@angular/` and `@nguniversal/` packages across multiple major versions.
Example to update from version 11 to version 13 the recommand approach is to run the following commands
```
ng update @angular/core@12
ng update @angular/core@13 (which is the same as ng update @angular/core)
```
NB: It is recommand that when update from one major to another, users verify that their applications is working as expected.
PR Close#43942
Since the `destroyAfterEach` teardown behavior is enabled by default now, existing tests that depended on the old behavior can start to fail. These changes add an automated migration that explicitly adds `destroyAfterEach: false` to existing tests.
The migration works by looking for `initTestEnvironment` calls across the entire app and adding the flag to them. If no calls were found, the migration will add the flag to all `configureTestingModule` and `withModule` calls instead.
PR Close#43353
The previous behavior of `RouterLink` for `null` and `undefined` inputs was to treat
the input the same as `[]` or `''`. This creates several unresolvable issues with
correctly disabling the links because `commands = []` does not behave the same
as disabling a link. Instead, it navigates to the current page, but will also
clear any fragment and/or query params.
The new behavior of the `routerLink` input will be to completely disable navigation
for `null` and `undefined` inputs. For HTML Anchor elements, this will also mean
removing the `href` attribute.
Migration for change in #43087
PR Close#43176
With this change we add a migration to replace the deprecated shadow-piercing selector from `/deep/` with deprecated but recommended `::ng-deep`.
The main motivation for this change is that the CSS optimizer CSSNano which is used by the Angular CLI no longer supports this non standard selector and causes build time errors due to the selector being minified incorrectly. However, CSSNano does support the recommended deprecated `::ng-deep` selector.
Closes: #42196
PR Close#42214
Adds a migration that casts the value of `ActivatedRouteSnapshot.fragment` to be non-nullable.
Also moves some code from the `AbstractControl.parent` migration so that it can be reused.
Relates to #37336.
PR Close#41092
`Route` configs with `redirectTo` as well as `canActivate` are not valid
because the `canActivate` guards will never execute. Redirects are
applied before activation. There is no error currently for these
configs, but another commit will change this so that an error does
appear in dev mode. This migration fixes the configs by removing the
`canActivate` property.
PR Close#40067
Add a schematic to update users to the new v11 `initialNavigation`
options for `RouterModule`. This replaces the deprecated/removed
`true`, `false`, `legacy_disabled`, and `legacy_enabled` options
with the newer `enabledBlocking` and `enabledNonBlocking` options.
PR Close#36926
Adds a migration that finds all imports and calls to the deprecated `async` function from
`@angular/core/testing` and replaces them with `waitForAsync`.
These changes also move a bit of code out of the `Renderer2` migration so that it can be reused.
PR Close#39212
As of #32671, the type of `AbstractControl.parent` can be null which can cause
compilation errors in existing apps. These changes add a migration that will append
non-null assertions to existing unsafe accesses.
````
// Before
console.log(control.parent.value);
// After
console.log(control.parent!.value);
```
The migration also tries its best to avoid cases where the non-null assertions aren't
necessary (e.g. if the `parent` was null checked already).
PR Close#39009
The default value for `relativeLinkResolution` is changing from 'legacy' to 'corrected'.
This migration updates `RouterModule` configurations that use the default value to
now specifically use 'legacy' to prevent breakages when updating.
PR Close#38698
In #38227 the signatures of `navigateByUrl` and `createUrlTree` were updated to exclude unsupported
properties from their `extras` parameter. This migration looks for the relevant method calls that
pass in an `extras` parameter and drops the unsupported properties.
**Before:**
```
this._router.navigateByUrl('/', {skipLocationChange: false, fragment: 'foo'});
```
**After:**
```
this._router.navigateByUrl('/', {
/* Removed unsupported properties by Angular migration: fragment. */
skipLocationChange: false
});
```
These changes also move the method call detection logic out of the `Renderer2` migration and into
a common place so that it can be reused in other migrations.
PR Close#38825
Static methods that return a type of ModuleWithProviders currently
do not have to specify a type because the generic falls back to any.
This is problematic because the type of the actual module being
returned is not present in the type information.
Since Ivy uses d.ts files exclusively for downstream packages
(rather than metadata.json files, for example), we no longer have
the type of the actual module being created.
For this reason, a generic type should be added for
ModuleWithProviders that specifies the module type. This will be
required for all users in v10, but will only be necessary for
users of Ivy in v9.
PR Close#33217
Re-enables the dynamic queries migration, now that we have all of the necessary framework changes in place.
Also moves the logic that identifies static queries out of the compiler and into the static queries migration, because that's the only place left that's using it.
PR Close#32992
Initially the `missing-injectable` migration was only being used
in google3. Wiring the migration up in the CLI migrations was
planned to be done in a follow-up.
PR Close#32349
Apparently the names of the bazel test targets in the schematics are
incorrect. This commit updates the target names to match their bazel
package name.
PR Close#32318
Initially the plan was to have a migration that adds `@Injectable()` to
all pipes in a CLI project so that the pipes can be injected in Ivy
similarly to how it worked in view engine.
Due to the planned refactorings which ensure that `@Directive`, `@Component`
and `@Pipe` also have a factory definition, this migration is no longer
needed for Ivy. Additionally since it is already disabled (due to
572b54967c) and we have a more generic
migration (known as `missing-injectable)` that could do the same as
`injectable-pipe`, we remove the migration from the code-base.
PR Close#32184
Introduces a new migration schematic that follows the given
migration plan: https://hackmd.io/@alx/S1XKqMZeS.
First case: The schematic detects decorated directives which
inherit a constructor. The migration ensures that all base
classes until the class with the explicit constructor are
properly decorated with "@Directive()" or "@Component". In
case one of these classes is not decorated, the schematic
adds the abstract "@Directive()" decorator automatically.
Second case: The schematic detects undecorated declarations
and copies the inherited "@Directive()", "@Component" or
"@Pipe" decorator to the undecorated derived class. This
involves non-trivial import rewriting, identifier aliasing
and AOT metadata serializing
(as decorators are not always part of source files)
PR Close#31650
Matthieu Riegler