ivy loses query results in abstract @Directive() when CLI rebuilt (file change)

[elvisbegovic]

🐞 Bug report

Command

- [x] serve

Description

In IVY v9 (see here), we'll need to add abstract @Directive() on abstracts classes we extends that contain Angular stuff (like Input, ViewChild, DI).
After add @Directive() on my abstract class and run ng serve everything works well.
But If I edit abstract directive file and save, browser autoreload but query results are not resolved anymore ?!?!

🔬 Minimal Reproduction

One line repro :
git clone https://github.com/elvisbegovic/issue-ivy-abstract-directive.git && cd issue-ivy-abstract-directive && npm i && ng s

Open browser localhost:4200, open devtools console, you will see consoel without error, viewchild is available.

Edit or comment anything in any-abstract-class.ts file (cli rebuild + autoreload browser) you can see error at runtime that viewchild this.myList is undefined.

GIF:

🔥 Exception or Error

After browser auto reload :

ERROR TypeError: Cannot read property 'name' of undefined
    at AppComponent.ngOnInit (any-abstract-class.ts:11)
    at AppComponent.ngOnInit (app.component.ts:17)
    at callHook (core.js:7864)
    at callHooks (core.js:7828)
    at executeInitAndCheckHooks (core.js:7769)
    at refreshView (core.js:12199)
    at renderComponentOrTemplate (core.js:12288)
    at tickRootContext (core.js:13648)
    at detectChangesInRootView (core.js:13683)
    at RootViewRef.detectChanges (core.js:15205)

In CLI console :
ERROR in src/app/app.component.ts(8,5): error TS8001: 'my-list' is not a valid HTML element.

🌍 Your Environment

See environment

Angular CLI: 9.0.0-next.2
Node: 12.9.1
OS: win32 x64
Angular: 9.0.0-next.4
... animations, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router
Package                           Version
@angular-devkit/architect         0.900.0-next.2

@angular-devkit/build-angular     0.900.0-next.2

@angular-devkit/build-optimizer   0.900.0-next.2

@angular-devkit/build-webpack     0.900.0-next.2

@angular-devkit/core              9.0.0-next.2

@angular-devkit/schematics        9.0.0-next.2

@angular/cli                      9.0.0-next.2

@ngtools/webpack                  9.0.0-next.2

@schematics/angular               9.0.0-next.2

@schematics/update                0.900.0-next.2

rxjs                              6.4.0

typescript                        3.5.3

webpack                           4.39.3

Anything else relevant?
Problem is only when you edit any-abstract-class.ts file, if after first build you edit other file = no error.

If I add selector to Directive and add it to NgModule declarations[], all works as before.

This is working in View Engine (jit and aot and without decorating abstract classes)

Maybe related to #31560 and all referenced issues

Maybe this can live on angular/angular ?

[petebacondarwin]

I think this is a problem with ngtsc incremental compilation?

[petebacondarwin]

I think the solution would be for ngtsc to include all ancestors of components as dependencies that would trigger a rebuild of that component.

[alxhub]

This shouldn't need to be the case (for locality) but probably should be because of type-checking.

[elvisbegovic]

Will this be solved for 9.0 final?

[petebacondarwin]

I think it should. We just need someone with time to look into it. :-/

[brgrz]

This also happens when no Directives are involved (only components). I have a setup of AppComponent and LayoutComponent and only included the LayoutComponent within the AppComponent markup and the project runs fine immediately after ng serve then breaks down (meaning noth in LayoutComponent gets rendered) after the first CSS/Less/HTML change in any of the two components.

Thankfully setting enableIvy to false solves this.

[JoostK]

Here's a breakdown of the issue:

Abstract directives are not registered with an NgModule, so if the directive is updated the NgModule is not invalidated. The component subclass however is correctly tracked as being dependent on its parent. During incremental state reconciliation, this means that the change to the abstract directive has this effect:

1. Metadata for the abstract directive is dropped, as the directive has changed.
2. Metadata for the component is dropped, as one of its dependencies has changed.
3. Metadata for the NgModule is kept, as no dependent file was changed.

During the subsequent compilation, the NgModule is considered to be safe to skip, which means that none of its metadata is analyzed and registered with LocalModuleScopeRegistry. Basically, this code is not executed:

angular/packages/compiler-cli/src/ngtsc/scope/src/local.ts

Lines 113 to 119 in a42057d

	registerNgModuleMetadata(data: NgModuleMeta): void {
	this.assertCollecting();
	this.moduleToRef.set(data.ref.node, data.ref);
	for (const decl of data.declarations) {
	this.declarationToModule.set(decl.node, data.ref.node);
	}
	}

Notice how this is responsible for the knowledge of which declarations correspond with which NgModule.

The abstract directive and component are reanalyzed, because their source file is correctly deemed unsafe to skip analyzing. Consequently, the component requests its module scope:

1. the LocalModuleScopeRegistry does not have the required information, as the NgModule was not analyzed so no metadata is present locally.
2. the IncrementalState.getScopeForComponent is considered, however the scope info that was set aside during the first compilation here:

angular/packages/compiler-cli/src/ngtsc/scope/src/local.ts

Lines 129 to 131 in a42057d

	if (scope !== null) {
	this.componentScopeRegistry.registerComponentScope(clazz, scope);
	}

is no longer available, as the component resides in a file for which no metadata was copied over during incremental state reconciliation as its metadata was deemed outdated (because of the dependency on the abstract directive).

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}