2

I've created a sample Angular 6 Library with the angular cli

  1. ng new test-lib
  2. ng g library my-lib

This gives me the basic structure with the angular library "my-lib" and the sample app "test-lib" which I think can be used for testing purpose.

Inside the library, I want to use dynamic imports. I have a class which should be imported lazily:

export class Lazy {
    print(): void {
        console.log('I am lazy');
    }
}

And I have my consumer component:

export class MyLibComponent implements OnInit {

  async ngOnInit() {
    const lazyImport = await import(/* webpackChunkName: 'lazy' */ './lazy');
    new lazyImport.Lazy().print();
  }
}

That's more or less about it. I use "ng build my-lib" to compile the library to the dist folder. In the tsconfig, I changed the "module" to esnext, to support dynamic imports.

Now I want to use the library inside of the sample app, which was generated by the cli. So inside of the app.module.ts, I import the module of the library and in the template of the app.component.ts, I add the corrensponding selector.

When I now build the sample app with "ng build" or start with "ng serve" I can see that there is no "lazy chunk" generated. It's just the normal main, polyfills, runtime, styles and vendor. What am I missing? Is it not possible to use dynamic load inside of a library?

When I change the import path inside of the app.module.ts from the compiled dist folder

import { MyLibModule } from 'my-lib';

to the librarys source code

import { MyLibModule } from '../../projects/my-lib/src/public_api';

the lazy chunk get's created and everything works as expected. But that's of course not what I want. I wand to use the compiled library inside of a totally different project where I can not import from the typescript sources.

Edit: Summary of my problem
Can a library itself perform dynamic loading or does this feature only work for the main-app to lazy load other parts of the app or additional libraries?!

Edit: Reason for the question
My library consists of hundreds of generated typescript classes. Per use case, only a few are needed. These should be loaded on demand.

Thanks for your help!
Stephan

Stephan U
  • 21
  • 3
  • Have you tried it? I don't see any reason to assume it doesn't. I would suggest placing multiple dynamic imports inside the library, and building it to see what the build output is. I don't see any evidence here to the contrary. – Avin Kavish Oct 08 '18 at 11:39
  • Yeah I did. That's what I tried to explain with this little example library from the first post. – Stephan U Oct 08 '18 at 12:53
  • @StephanU did you find a solution? I'm looking for a way to lazily load routes from my library. Appreciate for any help. – Romko Feb 27 '19 at 15:40

1 Answers1

0

It's working perfectly as intended. You just need to build the library, place it where you need it and use the dynamic import method in the other project and refer to your built library with a relative path.

The reason Angular-CLI doesn't build a chunk is because it tree-shakes out anything that is not being referred to in source code. If your import does not point to the lazy chunk it sees no reason to build it when ng build or ng serve is called on the app. But ng build my-lib will still explicitly build the module.

Avin Kavish
  • 8,317
  • 1
  • 21
  • 36
  • Thanks for your answer but I do not want to lazy load the whole library. Instead, the library itself should lazy load additional parts of the library. So the dynamic import must stay in the library. To give a reason for my question: The library will consist of hundreds of generated classes, but only a few are needed, depending on the use case. So it's not an option to have one big library, instead I need the library split in many small parts which get lazy loaded. – Stephan U Oct 08 '18 at 10:49
  • Hmmm... the wording is very confusing but I would suggest creating additional libraries for parts that needs to be lazy loaded. Lazy loading implies a separation of concerns and therefore the code must be split-table into sub-libraries similar to how `@angular` is split into a gazillion sub-libraries such as `@angular/core`, `@angular/router` and `@angular/common` – Avin Kavish Oct 08 '18 at 10:55