Fixes that the migration host was doing a basic falsy check if the content was read correctly which meant that a component with an empty template would be considered as having a missing template file.
Fixes#48846.
PR Close#48849
We dropped support for TypeScript 4.7 in version 15, but we had to keep around the runtime code, because of g3. Now that g3 is on 4.8, we can remove the additional code.
PR Close#48470
Fixes that imports weren't being combined in the `ImportManager` when multiple new imports are added for the same file. This wasn't a problem for previous schematics that used the manager, but it'll come up in some of the new ones.
Also moves the logic for writing new imports into `recordChanges`, instead of `addImportToSourceFile`.
PR Close#48620
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
- 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
Jessica Janiuk