angular: 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?

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 38 (20 by maintainers)

Commits related to this issue

Most upvoted comments

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.

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.

So having talked offline to @alan-agius4 - I understand a bit more now.

With a solutions-style layout it is no longer possible for any of our compilers: ngcc, ngc or even tsc to infer the tsconfig file to use and it must be provided explicitly.

  1. At the least we should document this
  2. Additionally we could provide a warning in ngcc if the inferred tsconfig is found to be a solutions style file
  3. Possibly we could consider trying to use one or more of the references to compute the configuration for ngcc to use

By the way, @alan-agius4 reminded me that this statement is not correct:

Hmm, so I don’t think that your paths should be pointing to the dist folder for your application. Just point them directly at the source:

You should never point at the source but at the compiled files.

That being said when using paths to point at a local library from a test app, I believe that you should normally be using ivy built libraries in the dist folder (i.e. not building them with --prod). This will completely avoid the need for ngcc to be run on those local libraries and will speed up your builds and make incremental builds more reliable. (@alan-agius4 can confirm if I have got this wrong too 😃 )