1a26f6da6e
Currently all of our migrations are set up to find the tsconfig paths within a project, create a `Program` out of each and migrate the files inside of the `Program`. The problem is that the `Program` can include files outside of the project and the CLI APIs that we use to interact with the file system assume that all files are within the project. These changes consolidate the logic, that determines whether a file can be migrated, in a single place and add an extra check to exclude files outside of the root. Fixes #39778. PR Close #39790 |
||
|---|---|---|
| .. | ||
| google3 | ||
| BUILD.bazel | ||
| README.md | ||
| collector.ts | ||
| index.ts | ||
| transform.ts | ||
| update_recorder.ts | ||
| util.ts | ||
README.md
initialNavigation migration
Automatically migrates the initialNavigation property of the RouterModule to the newly
available options: enabledNonBlocking (default), enabledBlocking, and disabled.
Before
import { NgModule } from '@angular/core';
import { RouterModule } from '@angular/router';
@NgModule({
imports: [
RouterModule.forRoot(ROUTES, {initialNavigation: 'legacy_disabled'}),
]
})
export class AppModule {
}
After
import { NgModule } from '@angular/core';
import { RouterModule } from '@angular/router';
@NgModule({
imports: [
RouterModule.forRoot(ROUTES, {initialNavigation: 'disabled'}),
]
})
export class AppModule {
}
Disclaimer
The migration only covers the most common patterns where developers set the ExtraOptions#InitialNavigation
option to an outdated value. Therefore, if a user declares the option using a number of other methods,
e.g. shorthand notation, variable declaration, or some other crafty method, they will have to migrate
those options by hand. Otherwise, the compiler will error if the types are sufficiently enforced.
The basic migration strategy is as follows:
legacy_disabled||false=>disabledlegacy_enabled||true=>enabledNonBlocking(new default)