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
- This update is needed to implement the changes in `ng add localize` https://github.com/angular/angular/pull/47569
- Add missing `root` options to all `angular.json`, this is required as otherwise the angular.json validation will fail.
- Remove `require.context` from test.ts integration test, as this is no longer needed.
- Update payloads golden files.
PR Close#47584
The Angular CLI has removed the JSON5 parsing and now always uses
`jsonc-parser`. Our test checks if JSON5 features can be parsed, but
this now breaks and the test needs to be adjusted.
We still want to keep the test to ensure we do not parse the Angular
CLI workspace file in a different way, not e.g. supporting jsonc.
PR Close#46642
This PR strongly types the forms package by adding generics to AbstractControl classes as well as FormBuilder. This makes forms type-safe and null-safe, for both controls and values.
The design uses a "control-types" approach. In other words, the type parameter on FormGroup is an object containing controls, and the type parameter on FormArray is an array of controls.
Special thanks to Alex Rickabaugh and Andrew Kushnir for co-design & implementation, to Sonu Kapoor and Netanel Basal for illustrative prior art, and to Cédric Exbrayat for extensive testing and validation.
BREAKING CHANGE: Forms classes accept a generic.
Forms model classes now accept a generic type parameter. Untyped versions of these classes are available to opt-out of the new, stricter behavior.
PR Close#43834
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
Drops support for TypeScript older than 4.6 and removes some workarounds in the compiler.
BREAKING CHANGE:
TypeScript versions older than 4.6 are no longer supported.
PR Close#45394
Previously, the migration only migrated constructor calls. Now, the migration will rewrite every usage, in all contexts. Both ways are technically correct, but migrating all symbols is likely to produce clearer and more readable results.
PR Close#45311
Consider a file that imports `FormControl` and then never uses it. In that case, we don't need to add the import for `UntypedFormControl`.
By examining constructor calls *first*, we can identify these cases and skip over them.
This will reduce the memory footprint of the migration when run in tsunami, hopefully making OOM errors less likely.
PR Close#45288
The typed forms migration was previously designed to add `<any>` type parameters to existing forms classes. However, due to some design changes, the new opt-out strategy requires untyped versions of the classes, as introduced in #45205 and #45268.
This PR updates the migration to import these new classes (in an idempotent manner), and replace constructor calls with the new classes. It respects qualified imports as well. Finally, the code has been refactored to move as much common code as possible into `util.ts`.
PR Close#45281
Proactively replaces our usages of the deprecated `ts.create*` methods in favor of using `ts.factory.create*` so that we're not surprised when the TS removes them in the future. Also accounts for some cases where the signature had changed.
PR Close#45134
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 reverts commit 894fa759f1. In that commit, the migration was completely diabled in order to prevent users from selecting it for the 13.2 release. This revert commit restores the migration to its previous (fully optional) state, in order to continue migration-focused work.
PR Close#44834
It's best to disable this optional migration in the minor release, although it shouldn't run anyway -- we don't want people accidentally running it.
This PR will be rolled back after the minor is out.
PR Close#44828
Make the following fixes:
* When submitting the entire migration in a disabled state, I commented out more code than strictly required
* Responding to some final review comments caused two conditions to become flipped
* Always use explicit checks instead of boolean corecion
* Fix one missed any cast in a test case
PR Close#44540
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
Cleans up some of the temporary workarounds that were necessary in order to land support for TypeScript 4.5 since they're no longer necessary.
PR Close#44477
Adds support for TypeScript 4.5. Includes the following changes:
* Bumping the package versions.
* Fixing a few calls to `createExportSpecifier` and `createImportSpecifier` that require an extra parameter.
* Adding some missing methods to the TS compiler hosts.
* Fixing an issue in the TS mocks for the ngcc tests where a regex was too agressive and was trying to match a path like `/node_modules/@typescript/lib-es5`.
* Accounting for type-only import specifiers when reporting DI errors (see #43620).
Fixes#43620.
PR Close#44164
Set up exporting the migration rules from the google3 directly from the internal
@angular/migrations package. This package is an internal only package to be
exposed for loading TSLint rules.
PR Close#43980
The `NgComponentTemplateVisitor` helper was always referring back to the original source file on disk
rather than the virtual file in the migration. This meant that some template migrations could attempt
to modify the template multiple times resulting in invalid output.
As an example the `migration-v13-router-link-empty-expression` migrates the following template:
```
<div [routerLink]></div>
```
to
```
<div [routerLink]="[]"></div>
```
But if the template was referenced multiple times in the program, such as when the component was
referenced in the source and test entry-points, the migration would result in things like:
```
<div [routerLink]="[]"="[]"></div>
```
Fixes#44005.
PR Close#44013
Previously, when parsing code for templates to migrate, CRLF characters were converted to just LF.
This meant that the source-spans being used to overwrite the template strings in the original source code were out of sync with the positions identified in the parsed templates.
This commit fixes this by parsing the raw text of the template taken from the source code instead of processed string contents.
Fixes#44005
PR Close#44013
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
Currently the TestBed teardown migration is set up in a similar way to all other migrations where we take a `CallExpression`, add a parameter to it, print it, and replace the existing call. The problem is that doing so while preserving the `expression` of the original `CallExpression` can cause comments to be duplicated. This can happen quite frequently, because by default the CLI generates comments before `initTestModule` calls.
To work around it, these changes make the migration more precise by inserting a new parameter or replacing and existing one using string manipulation.
This requires a bit more code, but it's more reliable than the following alternatives:
1. Using `getFullStart` and `getFullWidth` to replace the node. This would work with our current setup, but the problem is that `getFullStart` also includes whitespace and newlines before the leading comment. This can cause us to mess up the user's formatting and figuring out which whitespace to keep and which one to remove is tricky.
2. Recreating the `CallExpression.expression` when constructing the new node. This would also work since it'll drop any existing comments, but the problem is that `CallExpression.expression` can be a wide variety of nodes which we would have to account for. We can't use `getMutableClone`, because it preserves the comments.
Fixes#43739.
PR Close#43776
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 `@angular/core` migrations are currently published as CommonJS and also not bundled. Schematics, of which migrations are a type, are currently required to be CommonJS modules due to the Schematics Runtime not yet supporting ESM-based schematics. To ensure that the migration files are loaded as CommonJS modules, a nested `package.json` file has been introduced within the `schematics` directory of the package to set the `type` field for all containing JavaScript files as CommonJS. Since the migrations are also not currently bundled and the `devmode` output used to build the migrations will replace all relative imports with fully-qualified module specifiers, an additional `exports` entry must be added to allow the fully-qualified module specifiers to correctly resolve. If `devmode` did not change the relative imports the additional entry would not be needed. Bundling would also remedy the situation and is the long-term path, especially once the migrations are converted to ESM. Additional followup changes should investigate bundling each migration. The additional `exports` entry should be removed if either `devmode` behavior is changed or the migrations are bundled.
PR Close#43657
Currently, migrations and schematics must be in CommonJS format. However, framework packages will only be ESM from v13 and onward. To support this configuration, dynamic import expressions are now used to load `@angular/compiler-cli` and its new secondary entry point `@angular/compiler-cli/private/migrations`. Dynamic imports within Node.js allow the `@angular/core` migrations’ CommonJS code to load ESM code. Unfortunately, TypeScript will currently, unconditionally down-level dynamic import into a require call. `require` calls cannot load ESM code and will result in a runtime error. To workaround this, a Function constructor is used to prevent TypeScript from changing the dynamic import. Once TypeScript provides support for keeping the dynamic import this workaround can be dropped and replaced with a standard dynamic import. Due to the use of the dynamic import, a reference to the dynamically loaded modules must now be passed to all locations that use values from the modules.
PR Close#43657
As outlined in the previous commit which enabled the `esModuleInterop`
TypeScript compiler option, we need to update all namespace imports
for `typescript` to default imports. This is needed to allow for
TypeScript to be imported at runtime from an ES module.
Similar changes are needed for modules like `semver` where the types incorrectly
suggest named exports that will not exist at runtime when imported from ESM.
This commit refactors all imports to match with the lint rule we have
configured in the previous commit. See the previous commit for more
details on why certain imports have been changed.
A special case are the imports to `@babel/core` and `@babel/types`. For
these a special interop is needed as both default imports, or named
imports break the other module format. e.g default imports would work
well for ESM, but it breaks for CJS. For CJS, the named imports would
only work, but in ESM, only the default export exist. We work around
this for now until the devmode is using ESM as well (which would be
consistent with prodmode and gives us more valuable test results). More
details on the interop can be found in the `babel_core.ts` files (two
interops are needed for both localize/or the compiler-cli).
PR Close#43431
Enables the `esModuleInterop` for all TypeScript compilations in the
project. This allows us to emit proper ESM-compatible code. e.g.
consider the following import:
```ts
import * as ts from 'typescript';
```
This import currently will break at runtime in NodeJS because the
`typescript` package is not shipping ESM. It's still a CommonJS module.
ES modules are able to import from `typescript` though, using an import
statement as above, but everything in `module.exports` is being exposed
as the `default` named export. TypeScript at runtime does not have any
other named exports, so for actual ESM compatibility, all of our imports
need to be switched to:
```
import ts from 'typescript';
```
The `esModuleInterop` option allows this to work even though the
`d.ts` file of TS currently suggests that there are _only_ named exports.
The TypeScript language service will now suggest the correct import form as
shown above. It doesn't enforce that unfortunately, but this commit also
adds a lint rule that enforces certain patterns so that we emit imports
that are compatible with both ESM and CJS output (CJS still needed here
since tests run with CJS devmode output still; this is a future project
to switch that over to ESM!)
PR Close#43431
The Angular Core and localize package currently use deep imports for
code that is shipped. This is problematic as we want to ship the
compiler-cli as full-ESM. To achieve this we need to use a bundler and
this breaks deep imports.
We use a bundler for the compiler CLI because for full ESM
compatibility, we would need to explicitly add the `.js` extension
to all relative imports. This is very cumbersome and prone to mistakes
so to mitigate this problem in a safe way, we bundle the compiler-cli.
Note: Deep imports continue to exist for the language service as it
bundles the compiler-cli.
PR Close#43431
This reverts commit ab3de40ba3, which is
itself a revert of the original commit. Thus, this restores the changes
to schematics in support of ESM.
Now that g3 has a local modification for load_esm, we can restore this
functionality.
PR Close#43637
Currently, migrations and schematics must be in CommonJS format. However, framework packages will only be ESM from v13 and onward. To support this configuration, dynamic import expressions are now used to load `@angular/compiler`. Dynamic imports within Node.js allow the `@angular/core` migrations’ CommonJS code to load ESM code. Unfortunately, TypeScript will currently, unconditionally down-level dynamic import into a require call. `require` calls cannot load ESM code and will result in a runtime error. To workaround this, a Function constructor is used to prevent TypeScript from changing the dynamic import. Once TypeScript provides support for keeping the dynamic import this workaround can be dropped and replaced with a standard dynamic import. Due to the use of the dynamic import, a reference to the compiler module must now be passed to all locations that use values from the `@angular/compiler` package.
PR Close#43627
A base class that can be used to implement a Render3 Template AST visitor is now used throughout the `@angular/core` migrations. This class is used instead of the `NullVisitor` found within the `@angular/compiler` because the `NullVisitor` requires a deep import which is no longer supported with the ESM bundled packages as of v13. The `NullVisitor` is also fairly trivial in regards to its implementation and the new base class also provides additional helper methods for migration specific behavior. This removes all remaining deep imports of the `@angular/compiler` package from the `@angular/core` migrations while avoiding the need to modify the `@angular/compiler` package.
PR Close#43627
Most of the deep imports into the `@angular/compiler` package in the `@angular/core` migrations are for template AST types that are available as exports from the main entry point of the package (albeit under slightly different names). For the available main entry point exports, the deep imports have been transitioned to no longer use the deep import.
PR Close#43627
Adds support for TypeScript 4.4. High-level overview of the changes made in this PR:
* Bumps the various packages to `typescript@4.4.2` and `tslib@2.3.0`.
* The `useUnknownInCatchVariables` compiler option has been disabled so that we don't have to cast error objects explicitly everywhere.
* TS now passes in a third argument to the `__spreadArray` call inside child class constructors. I had to update a couple of places in the runtime and ngcc to be able to pick up the calls correctly.
* TS now generates code like `(0, foo)(arg1, arg2)` for imported function calls. I had to update a few of our tests to account for it. See https://github.com/microsoft/TypeScript/pull/44624.
* Our `ngtsc` test setup calls the private `matchFiles` function from TS. I had to update our usage, because a new parameter was added.
* There was one place where we were setting the readonly `hasTrailingComma` property. I updated the usage to pass in the value when constructing the object instead.
* Some browser types were updated which meant that I had to resolve some trivial type errors.
* The downlevel decorators tranform was running into an issue where the Closure synthetic comments were being emitted twice. I've worked around it by recreating the class declaration node instead of cloning it.
PR Close#43281
The previous replacement logic would not account for the CRLF line
endings when applying replacements because it would replace the whole
template with `template.content.length` which would not account for
CRLF. This update applies individual expression edits at each location
in the template rather than attempting to replace the whole template
contents with a new string that contains the migrations.
fixes#43416
PR Close#43519
