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
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
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
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
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 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
With this change we change the logic to locate the tsconfig files. The public API to locate, read and parse the workspace configuration should be use instead of the custom implemented logic.
The custom implemented logic depended on methods which have long been deprecated and are not removed in version 13 of the Angular CLI. This was not caught during development/UT because this repo is using outdated Angular Tooling packages.
This change also updates a number of spec files which previously creating an invalid Angular workspace configuration file.
Closes#43334
PR Close#43343
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
In #38762 we added a migration to replace the deprecated `preserveQueryParams`
option with `queryParamsHandling`, however due to a typo, we ended up replacing it
with `queryParamsHandler` which is invalid.
Fixes#39755.
PR Close#39763
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
This is a roll forward of #39082, using `ts.createIdentifier(`'legacy'`)` as a cross-version compatible way of making
a single quoted string literal.
Migrated code now uses single quotes, which is in line with the default linting options, so there is no lint error after
migration.
PR Close#39102
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
This updates the migration to align with the style guide and work with default lint rules. It avoids a lint error on
newly migrated projects and fixes a test in the CLI repo.
PR Close#39070
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
As of v10, the `undecorated-classes-with-decorated-fields` migration
generally deals with undecorated classes using Angular features. We
intended to run this migation as part of v10 again as undecorated
classes with Angular features are no longer supported in planned v11.
The migration currently behaves incorrectly in some cases where an
`@Injectable` or `@Pipe` decorated classes uses the `ngOnDestroy`
lifecycle hook. We incorrectly add a TODO for those classes. This
commit fixes that.
Additionally, this change makes the migration more robust to
not migrate a class if it inherits from a component, pipe
injectable or non-abstract directive. We previously did not
need this as the undecorated-classes-with-di migration ran
before, but this is no longer the case.
Last, this commit fixes an issue where multiple TODO's could be
added. This happens when multiple Angular CLI build targets have
an overlap in source files. Multiple programs then capture the
same source file, causing the migration to detect an undecorated
class multiple times (i.e. adding a TODO twice).
Fixes#37726.
PR Close#37732
Enables the `ng update` migrations for v10. Status for individual
migrations:
**undecorated-classes-with-di**.
This migration dealt exlusively with inherited constructors and
cases where a derived component was undecorated. In those cases,
the migration added `@Directive()` or copied the inherited decorator
to the derived class.
We don't need to run this migration again because ngtsc throws if
constructor is inherited from an undecorated class. Also ngtsc will
throw if a NgModule references an undecorated class in the declarations.
***undecorated-classes-with-decorated-fields***
This migration exclusively deals with undecorated classes that use
Angular features but are not decorated. Angular features include
the use of lifecycle hooks or class fields with Angular decorators,
such as `@Input()`.
We want to re-run this migration in v10 as we will disable the
compatibility code in ngtsc that detects such undecorated classes
as `@Directive`.
**module-with-providers**:
This migration adds an explicit generic type to `ModuleWithProviders`.
As of v10, the generic type is required, so we need to re-run the
migration again.
**renderer-to-renderer2**:
We don't need to re-run that migration again as the
renderer has been already removed in v9.
**missing-injectable**:
This migration is exclusively concerned with undecorated
providers referenced in an `NgModule`. We should re-run
that migration again as we don't have proper backsliding
prevention for this yet. We can consider adding an error
in ngtsc for v10, or v11. In either way, we should re-run
the migration.
**dynamic-queries**:
We ran this one in v9 to reduce code complexity in projects. Instead
of explicitly passing `static: false`, not passing any object literal
has the same semantics. We don't need to re-run the migration again
since there is no good way to prevent backsliding and we cannot always
run this migration for future versions (as some apps might actually
intentionally use the explicit `static: false` option).
PR Close#36921
As of v10, undecorated classes using Angular features are no longer
supported. In v10, we plan on removing the undecorated classes
compatibility code in ngtsc. This means that old patterns for
undecorated classes will result in compilation errors.
We had a migration for this in v9 already, but it looks like
the migration does not handle cases where classes uses lifecycle
hooks. This is handled in the ngtsc compatibility code, and we
should handle it similarly in migrations too.
This has not been outlined in the migration plan initially,
but an appendix has been added for v10 to the plan document.
https://hackmd.io/vuQfavzfRG6KUCtU7oK_EA?both.
Note: The migration is unable to determine whether a given undecorated
class that only defines `ngOnDestroy` is a directive or an actual
service. This means that in some cases the migration cannot do
more than adding a TODO and printing an failure.
Certainly there are more ways to determine the type of such classes,
but it would involve metadata and NgModule analysis. This is out of
scope for this migration.
PR Close#36921
Based on the migration guide, provided classes which don't have
either `@Injectable`, `@Directive`, `@Component` or `@Pipe` need
to be migrated.
This is not correct as provided classes with an `@NgModule` also
have a factory function that can be read by the r3 injector. It's
unclear in which cases the `@NgModule` decorator is used for
provided classes, but this scenario has been reported.
Either we fix this in the migration, or we make sure to report
this as unsupported in the Ivy compiler.
Fixes#35700.
PR Close#36369
Paul Gschwendtner