Angular 9 (Ivy) App build with local library (mono-repo) failing

🐞 Bug report

Command (mark with an x)

• new
• build
• serve
• test
• e2e
• generate
• add
• update
• lint
• xi18n
• run
• config
• help
• version
• doc

Is this a regression?

Haven’t tested in older version, so i’m unsure, but considering that this is Ivy related, i would imagine it is regression.

Description

I have an Angular 9 app that i’m starting to move some of the components into a dedicated library project, which uses secondary entry points (trying to mimic Angular Material’s approach). Everything builds fine if i build both library and app with the Ivy compiler, but if i build both with the --prod flag (which causes the library to be built without Ivy), the app build fails with the following error:

Compiling @fabric/components/breadcrumbs : es2015 as esm2015

ERROR in node_modules/@fabric/components/breadcrumbs/fab-breadcrumbs.module.d.ts:1:22 - error NG6002: Appears in the NgModule.imports of AppModule, but could not be resolved to an NgModule class.

This likely means that the library (@fabric/components/breadcrumbs) which declares FabBreadcrumbsModule has not been processed correctly by ngcc, or is not compatible with Angular Ivy. Check if a newer version of the library is available, and update if s
o. Also consider checking with the library's authors to see if the library is expected to be compatible with Ivy.

1 export declare class FabBreadcrumbsModule {
                       ~~~~~~~~~~~~~~~~~~~~

I tried updating to the latest version (9.0.2 -> 9.1.0), but it’s still doing the same thing. I tried recreating this with a brand new super simple mono-repo project, but in that simple case it works fine. I compared the tsconfig and angular.json config files between my app and the simple working app, but they’re fairly identical. As a last resort, i added "postinstall": "ngcc" to my root package.json, wiped out my library’s folder in my node_modules dir, and re-ran npm install. This forced ngcc to run on everything including my library. After that, the app build worked as it should. So it would seem that the app build isn’t recognizing that the library build was done with viewEngine and kicking off the ngcc itself?

🔥 Exception or Error

Compiling @fabric/components/breadcrumbs : es2015 as esm2015

ERROR in node_modules/@fabric/components/breadcrumbs/fab-breadcrumbs.module.d.ts:1:22 - error NG6002: Appears in the NgModule.imports of AppModule, but could not be resolved to an NgModule class.

This likely means that the library (@fabric/components/breadcrumbs) which declares FabBreadcrumbsModule has not been processed correctly by ngcc, or is not compatible with Angular Ivy. Check if a newer version of the library is available, and update if s
o. Also consider checking with the library's authors to see if the library is expected to be compatible with Ivy.

1 export declare class FabBreadcrumbsModule {
                       ~~~~~~~~~~~~~~~~~~~~

🌍 Your Environment

Angular CLI: 9.1.0
Node: 12.13.0
OS: win32 x64

Angular: 9.1.0
... animations, cli, common, compiler, compiler-cli, core, forms
... language-service, localize, platform-browser
... platform-browser-dynamic, router
Ivy Workspace: Yes

Package                            Version
------------------------------------------------------------
@angular-devkit/architect          0.901.0
@angular-devkit/build-angular      0.901.0
@angular-devkit/build-ng-packagr   0.901.0
@angular-devkit/build-optimizer    0.901.0
@angular-devkit/build-webpack      0.901.0
@angular-devkit/core               9.1.0
@angular-devkit/schematics         9.1.0
@angular/cdk                       9.2.0
@angular/material                  9.2.0
@ngtools/webpack                   9.1.0
@schematics/angular                9.1.0
@schematics/update                 0.901.0
ng-packagr                         9.1.0
rxjs                               6.5.4
typescript                         3.8.3
webpack                            4.42.0

Anything else relevant?

[petebacondarwin]

Created a PR to log the warning (i.e. 2. from above). This would also act to document the issue (on-demand) so arguably it fixes 1. from above too.

[michaelfaith]

Makes sense. I guess i don’t fully appreciate the benefits of the solution-style layout, as it is. But i think any of those options would definitely help. The third would probably be best, but obviously require more work to implement. I guess in the interim, sounds like i could either just undo the solution-style layout change, or add the --tsconfig flag to the postinstall ngcc call, which are both viable options. Appreciate all the help figuring this out. I’d like to get to the point where i could actually help contribute changes for stuff like this. Will review your contributing guidelines.