ivy throw [tagName] is not a known element

🐞 bug report

Affected Package

I think, the issue is caused by package @angular/core

Is this a regression?

Yes, it works in ViewEngine

Description

In angular v9 rc1 enable ivy with certain 3th party lib throw * is not known element

🔬 Minimal Reproduction

One line repro : git clone https://github.com/elvisbegovic/ivy-tag-is-not-a-known-element.git && cd ivy-tag-is-not-a-known-element && npm i && ng s -o

Compilation/serve is OK, but at runtime (open dev tools) error is:

🔥 Exception or Error

core.js:6068 ERROR Error: 'tree-viewport' is not a known element:
1. If 'tree-viewport' is an Angular component, then verify that it is part of this module.
2. If 'tree-viewport' is a Web Component then add 'CUSTOM_ELEMENTS_SCHEMA' to the '@NgModule.schemas' of this component to suppress this message.
    at validateElement (core.js:23156)
    at Module.ɵɵelementStart (core.js:22963)
    at TreeComponent_Template (tree.component.js:245)
    at executeTemplate (core.js:13684)
    at renderView (core.js:13486)
    at renderComponent (core.js:14841)
    at renderChildComponents (core.js:13291)
    at renderView (core.js:13512)
    at renderComponent (core.js:14841)
    at renderChildComponents (core.js:13291)

Snippet code of compiled tree.component.js

🌍 Your Environment

See Environment...

**Angular Version:**
<pre><code>
Angular CLI: 9.0.0-rc.1
Node: 12.13.0
OS: win32 x64
Angular: 9.0.0-rc.1
... animations, cli, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.900.0-rc.1
@angular-devkit/build-angular     0.900.0-rc.1
@angular-devkit/build-optimizer   0.900.0-rc.1
@angular-devkit/build-webpack     0.900.0-rc.1
@angular-devkit/core              9.0.0-rc.1
@angular-devkit/schematics        9.0.0-rc.1
@ngtools/webpack                  9.0.0-rc.1
@schematics/angular               9.0.0-rc.1
@schematics/update                0.900.0-rc.1
rxjs                              6.5.3
typescript                        3.6.4
webpack                           4.41.2
</code></pre>

✍️ Anything else relevant?

This breaks application at runtime, annoying we cannot see that durning build/serve step.

/cc @alxhub @petebacondarwin

[petebacondarwin]

I have identified the root, root cause of the problem in @elvisbegovic’s one-line reproduction. This is probably not the general problem for other commenters on this issue but see the bottom of my analysis for ideas in those cases.

1. The root cause is actually that angular-tree-component’s UMD build is not valid. Their use of rollup does not specify mobx, mobx-angular and lodash as external packages, which leads to the UMD bundle including these packages inline. Note that the ESM files do not bundle up these external libraries and instead imports them as expected.
2. ngcc computes dependencies between packages before processing them; it must ensure that packages are processed after their dependences. Do do this it parses just the first of the code formats that it recognises. Because it considers the package.json properties in this order - ['fesm2015', 'fesm5', 'es2015', 'esm2015', 'esm5', 'main', 'module'] it finds the main property (UMD) before the module property (ESM). So ngcc was using the broken UMD format for computing the dependencies and so missing the mobx-angular package.
3. Since mobx-angular was not found as a dependency of angular-tree-component the former was being processed “after” the latter, which meant that angular-tree-component had a missing dependency when it came to processing the ESM format (aka module).
4. The missing dependency during compilation can be identified as an error but is currently being swallowed.
5. The compilation (and so the ngcc processing) completes “successfully” but the directives used by the component are not generated in the rendered output, leading to the runtime errors we see here.

Possible resolutions:

1. Workaround by adding a ngcc.config.js that hides the main property in angular-tree-component so that we always use the module property for both processing and for dependency resolution.
2. Fix angular-tree-component - provide a PR to fix this package’s distributable (https://github.com/500tech/angular-tree-component/pull/771)
3. Change the order of dependency resolution properties, so that module is before main. I think it was originally in this order because it was felt that a single flat file would be parsed faster than having to load up a deep non-flat hierarchy of files; but it is also reasonable to assume that main is more likely to be “broken” than module in 3rd party libraries out there.
4. Add better diagnostic reporting to ngcc to help diagnose these scenarios. PR here https://github.com/angular/angular/pull/33964

[petebacondarwin]

With the change to the diagnostics reporting we get:

Compiling angular-tree-component : module as esm5
console_logger.ts:38
Error: Failed to compile entry-point angular-tree-component due to compilation errors:
node_modules/mobx-angular/dist/mobx-angular.d.ts(5,22): error TS-996002: Appears in the NgModule.imports of TreeModule, but could not be resolved to an NgModule class

which at least will tell us where to start looking and not leave us with an obscure runtime error.