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 | ||
| index.ts | ||
| util.ts | ||
README.md
Dynamic queries migration
Automatically migrates dynamic queries to remove their static flag. This flag will no
longer be necessary in version 9 for dynamic queries, as false is the default value.
Before
import { Directive, ViewChild, ContentChild, ElementRef } from '@angular/core';
@Directive()
export class MyDirective {
@ViewChild('child', { static: false }) child: any;
@ViewChild('secondChild', { read: ElementRef, static: false }) secondChild: ElementRef;
@ContentChild('thirdChild', { static: false }) thirdChild: any;
}
After
import { Directive, ViewChild, ContentChild, ElementRef } from '@angular/core';
@Directive()
export class MyDirective {
@ViewChild('child') child: any;
@ViewChild('secondChild', { read: ElementRef }) secondChild: ElementRef;
@ContentChild('thirdChild') thirdChild: any;
}