Declared in 2 Modules - Cannot compose new modules
See original GitHub issueI’m submitting a…
[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report
[x] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
Current behavior
Within a @nrwl/nx monorepository, you have 2 apps that consume modules to create a whole application. One of the consumed modules contains 3 components for layout: Header, Sidebar, Footer
App1 uses everything out of the box and everyones happy. App2 has a different Footer that requires replacing the component entirely, but would like to re-use Header and Sidebar from LayoutModule as nothing changed.
JIT works fine, but AOT gives the following error:
ERROR in :
Type FooterComponent in /Site/libs/layout/src/footer/footer.component.ts is part of the declarations of 2 modules:
LayoutModule in /Site/apps/myapp/src/app/layout/layout.module.ts
and
LayoutModule in /Site/libs/layout/src/layout.module.ts!
Please consider moving FooterComponent in /Site/libs/layout/src/footer/footer.component.ts to a higher module that imports LayoutModule
Expected behavior
Both JIT and AOT would compile without any errors. I’m not even using or referencing the original LayoutModule so it shouldn’t give an error.
Minimal reproduction of the problem with instructions
Repo: https://github.com/intellix/nx-cli
ng serve --app green // works
ng serve --app green --aot // does not
What is the motivation / use case for changing the behavior?
Modules are a composition of declared components and can be imported entirely from a lib. If you need to replace 1 component, it’s currently impossible if using AOT. The only way around it is to only ever have 1 component per Module, in which case I would have hundreds for an application.
We want to be able to create applications using modules of components from libs, but be able to replace components when we need to change them. Currently you have to throw away the whole module. I’d expect something like this to work if I don’t even use the previous module:
MyLibs/LayoutModule:
import { HeaderComponent } from './header/header.component';
import { SidebarComponent } from './sidebar/sidebar.component';
import { FooterComponent } from './footer/footer.component';
@NgModule({ declarations: [ HeaderComponent, SidebarComponent, FooterComponent ] })
export class LayoutModule { }
App1 (wants to use out of the box):
import { LayoutModule } from '@mylibs/layout';
@NgModule({ imports: [ LayoutModule ] })
export class AppModule { }
App2 (wants to replace Footer):
import { HeaderComponent, SidebarComponent } from '@mylibs/layout';
import { FooterComponent } from './footer.component';
@NgModule({ declarations: [ HeaderComponent, SidebarComponent, FooterComponent ] })
export class MyLayoutModule { }
@NgModule({ imports: [ MyLayoutModule ] })
export class AppModule { }
Environment
Angular version: 5.1.1
For Tooling issues:
- Node version: XX v8.9.1
- Platform: Mac
Others:
I think either ngc needs to either only give errors based on code used or ease up in this case. Even a warning would be nice
Issue Analytics
- State:
- Created 6 years ago
- Reactions:7
- Comments:10 (4 by maintainers)
I’ve created a diagram to show what I’m talking about that I hope explains it better: https://drive.google.com/file/d/1_8vpoh5o15-ZHLbKAEc6GygXzrc4gzw6/view?usp=sharing
Green: Shared Lib Red: Coca Cola Blue: Pepsi Yellow: Sprite
We’re essentially a white-labelling product company. If you’ve been to car insurance websites, you’ll notice they’re all the same website but are branded/coloured differently. Sometimes clients will request something slightly different/unique like a Product view but you don’t want to recreate the things that don’t change from that library.
Right now as it stands, the only solutions are:
Each component can only be part of a single used/referenced Module, but AOT should not be throwing errors for modules that are not referenced.
It’s throwing application context errors when it doesn’t understand applications (it only reads files found via TS resolution).
A workaround would be to at least disable the error until AOT only follows referenced code through entrypoints or at least allow a configurable for disabling it so mono-repository users can continue to use AOT. More of these issues are going to crop up as people use https://nrwl.io/nx