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
- fix(ngcc): report a warning if ngcc tries to use a solution-style tsconfig In CLI v10 there was a move to use the new solution-style tsconfig which became available in TS 3.9. The result of this is t... — committed to petebacondarwin/angular by petebacondarwin 4 years ago
- fix(ngcc): report a warning if ngcc tries to use a solution-style tsconfig In CLI v10 there was a move to use the new solution-style tsconfig which became available in TS 3.9. The result of this is t... — committed to petebacondarwin/angular by petebacondarwin 4 years ago
- fix(ngcc): report a warning if ngcc tries to use a solution-style tsconfig In CLI v10 there was a move to use the new solution-style tsconfig which became available in TS 3.9. The result of this is ... — committed to petebacondarwin/angular by petebacondarwin 4 years ago
- fix(ngcc): report a warning if ngcc tries to use a solution-style tsconfig (#38003) In CLI v10 there was a move to use the new solution-style tsconfig which became available in TS 3.9. The result of... — committed to angular/angular by petebacondarwin 4 years ago
- fix(ngcc): report a warning if ngcc tries to use a solution-style tsconfig (#38003) In CLI v10 there was a move to use the new solution-style tsconfig which became available in TS 3.9. The result of... — committed to angular/angular by petebacondarwin 4 years ago
- fix(ngcc): report a warning if ngcc tries to use a solution-style tsconfig (#38003) In CLI v10 there was a move to use the new solution-style tsconfig which became available in TS 3.9. The result of... — committed to profanis/angular by petebacondarwin 4 years ago
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 eventsc
to infer the tsconfig file to use and it must be provided explicitly.By the way, @alan-agius4 reminded me that this statement is not correct:
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 😃 )