Solvedangular cli Lazy loading module from library package located in node_modules fails to build.
✔️Accepted Answer
I've got work around for this which works with uirouter/angular-hybrid (in AOT mode too) but might work with angular router too.
So, let's say I've got a library based on angular-quickstart-lib (let's call it quickstart-lib) which has LibModule that I want to lazy load. To do so, I added wrapper around library which lives in Angular CLI based host project.
So, in app.module.ts of host, instead of:
@NgModule({
imports: [
UIRouterModule.forChild({
states: [
{
name: 'quickstart.**',
url: 'quickstart',
loadChildren: 'quickstart-lib#LibModule'
}
]}),
]
})
export class AppModule
I've got:
libModuleLazyLoader.ts
import { NgModule } from "@angular/core";
import { LibModule } from 'quickstart-lib';
@NgModule({
imports: [
LibModule
]
})
export class QuickstartLibLazyLoader {}
and then, in app.module.ts, I've got:
@NgModule({
imports: [
UIRouterModule.forChild({
states: [
{
name: 'quickstart.**',
url: 'quickstart',
loadChildren: './libModuleLazyLoader#QuickstartLibLazyLoader'
}
]}),
]
})
export class AppModule
Downside is that you'd need wrapper per library with this work around.
hope this helps someone :)
Other Answers:
Is it going to be fixed?
I was able to track down the issue. It appears that the AoT plugin discovers lazy routes and passes them to the angular compiler language service to resolve the file name of a given route string. Assuming your library is following the angular package format, this resolves to a definition file, e.g. c:...\node_modules\lib-name\lib-name.d.ts.
The file @ngtools\webpack\src\loader.js then uses this path to transpile the source code to es2015 which fails. I modified this file to check for the *.d.ts extension. If there is a match I just use the contents of the pre-compiled .js and .map files for the library. This lets me get past the compilation error in the CLI and when watching the network traffic, I can see the module is loaded on demand.
However, this is another hickup, the library is already bundled in the vendor.js file since the webpack configuration simply bundles everything in the node_modules directory into a the vendors file.
The only way to get around this, is to eject out of the CLI to exclude the library from the common vendor chunk.
All these fixes seem to be a hack, hopefully the cli team can come up with something more elegant.
@adamlubek it works! Thanks!
So why is this not a priority? Lets say we have a bigger business application where all pages are located in a lib. For each customer we create a custom app out of the pages. When you have so many pages Lazy Loading is the way to go because the startup time would be too high otherwise. Now I have to create a wrapper module for 50 pages to make it work correctly?? That is not a reasonable solution at all...
Bug Report or Feature Request (mark with an
x
)Versions.
Repro steps.
I've modified the quick start library from @filipesilva and copied the output folder to my node_modules/quickstart-lib directory.
Modification includes a routing module to add a child route.
which is then imported into the main LibModule file.
In my host application, I created a simple route to lazy load the module from the library
The log given by the failure.
Desired functionality.
I would like to distribute my code as an NPM library and have the CLI support lazy loading the module that is located in the 'node_modules' directory.
Modules located in the same application directory are lazy loaded just fine.
Mention any other details that might be useful.