angular
Template type checking re-builds do not run correctly when referencing a re-exported type
Which @angular/* package(s) are the source of the bug?
Don't known / other
Is this a regression?
Yes
Description
Consider the following example, running ng serve with template type checking turned on:
- An Angular template references a property on the component class in an expression.
- This component class properties type definition comes from a file which re-exports the type definition from another file.
- Re-builds do not always re-compile the template expression when they should.
More specifically, in the reproduction repo this looks as follows:
- The app component template includes an expression:
{{ myType?.abc }}. - The app component class defines the myType property:
myType?: MyTypeReExported. - The type of the myType property comes from a file which re-exports another type.
export type MyTypeRexported = MyType. - The type MyType comes from a file which defines the definition as:
export interface MyType { abc: 123; }. - The initial ng serve will run without errors.
- Changing the type definition of MyType to be
export interface MyType { abcd: 123; }causes an error in the app component's template. This is seen in the re-build console output. This is the correct behaviour. - Changing the type definition back to what it was originally should remove the error. However, it does not. That is the bug.
Please provide a link to a minimal reproduction of the bug
https://github.com/HazzMan2409/angular-template-rebuild-bug
Please provide the environment you discovered this bug in
Angular 12.2.5.
Node 14.17.6
See the package.json on the repo for more details. At the time 12.2.5 was the latest version.
Moving to the CLI repo as this is a bug in incremental type-checking and not observed with just ngc.
A quick update after debugging through the incremental type-checking logic: this issue occurs due to how TypeScript's builder APIs for incremental diagnostics computations fail to report indirectly affected files as affected, which causes the CLI to be unaware of those cache invalidations. The TS builder implementation only wipes its internal diagnostics cache for indirectly affected files (assuming that the assumeChangesOnlyAffectDirectDependencies compiler option is not set) but this side-effect cannot be observed using the builder's APIs, so we're left in the dark here.
The same issue also occurs for the more common pattern of having indirect property accesses and changing a nested property's signature; we're only recomputing typecheck results for the affected files based on the import graph but not based on signature changes.