d43c30688a
In rare cases a project with configured `rootDirs` that has imports to non-existent identifiers could fail in the migration. This happens because based on the application code, the migration could end up trying to resolve the `ts.Symbol` of such non-existent identifiers. This isn't a problem usually, but due to a upstream bug in the TypeScript compiler, a runtime error is thrown. This is because TypeScript is unable to compute a relative path from the originating source file to the imported source file which _should_ provide the non-existent identifier. An issue for this has been reported upstream: https://github.com/microsoft/TypeScript/issues/37731. The issue only surfaces since our migrations don't provide an absolute base path that is used for resolving the root directories. To fix this, we ensure that we never use relative paths when parsing tsconfig files. More details can be found in the TS issue. Fixes #36346. PR Close #36367 |
||
---|---|---|
.. | ||
BUILD.bazel | ||
README.md | ||
helpers.ts | ||
index.ts | ||
migration.ts | ||
util.ts |
README.md
Renderer -> Renderer2 migration
Automatically migrates from Renderer
to Renderer2
by changing method calls, renaming imports
and renaming types. Tries to either map method calls directly from one renderer to the other, or
if that's not possible, inserts custom helper functions at the bottom of the file.
Before
import { Renderer, ElementRef } from '@angular/core';
@Component({})
export class MyComponent {
constructor(private _renderer: Renderer, private _elementRef: ElementRef) {}
changeColor() {
this._renderer.setElementStyle(this._element.nativeElement, 'color', 'purple');
}
}
After
import { Renderer2, ElementRef } from '@angular/core';
@Component({})
export class MyComponent {
constructor(private _renderer: Renderer2, private _elementRef: ElementRef) {}
changeColor() {
this._renderer.setStyle(this._element.nativeElement, 'color', 'purple');
}
}