0.9.1 tslint lazy load modules check not working (when nested)

[ph55]

Description:

• Add lazy-loaded module to app routing.
  

• Import same module into another without lazy-load.
  

No tslint warning thrown.

Repo:

https://github.com/ph55/nx-lazy-load

Info:

Angular CLI: 1.7.1
Node: 8.9.4
OS: win32 x64
Angular: 5.2.6
... animations, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router

@angular/cli: 1.7.1
@angular-devkit/build-optimizer: 0.3.2
@angular-devkit/core: 0.3.2
@angular-devkit/schematics: 0.3.2
@ngtools/json-schema: 1.2.0
@ngtools/webpack: 1.10.1
@schematics/angular: 0.3.2
@schematics/package-update: 0.3.2
typescript: 2.6.2
webpack: 3.11.0

[skydever]

hi @ph55

In my opinion this is the expected behaviour - the same lib can be included lazy or eager (tried to explain that here), both is possible - but if you import it lazy, you are not allowed to also import it eager within the same app/lib.

Try this with your example:
Add import { LazyAModule } from '@nx-test/lazy-a'; somewhere in your app where you did the lazy loading for lazy-a - then you should get the lint error.
(e.g. add it in apps/test/src/app/app.component.ts)

About windows:
Is the nx workspace the main directory of your project? If not, does #341 help (I referenced the modified JS file to be replace manually in node_modules, for some quick tests)?

[ph55]

hi @skydever

Thanks for explanation.
You're right - if I 'eager-loading' module in same place where I 'lazy-loading' it - it throws error.
So it works.

But take a look at LazyCModule it's 'eager-loaded' in AppModule

And then both LazyAModule and LazyBModule eager loaded again when they already 'lazy-loaded' within AppModule.
Shouldn't it raise error as well ?
Or should it be handled by depConstraints.

AppModule
   -> LazyCModule (eager) -> LazyAModule(eager), LazyAModule (eager)
   -> LazyAModule(lazy), LazyAModule (lazy)

[skydever]

I am not sure what you are expecting, my thoughts on that are:

the rule does not check if a lazy loaded module is importing a module that was already eager loaded in the app or the other way round, and I think that's ok like this. lets say you have a classic shared module, you will import that module nearly everywhere, and you need to to have access to its components, also in the lazy loaded module. you don't have access to the components of LazyAModule within LazyCModule if you do not import it explicitly ...

about circular dependencies on that matter, I think this is ok too:
app -> LazyCModule (eager), LazyAModule (lazy), LazyBModule (lazy)
LazyCModule -> LazyAModule (eager), LazyBModule (eager)
LazyAModule -> no deps
LazyBModule -> no deps

[ph55]

Got it. Thanks.

[skydever]

I am happy if I could help. Still figuring out some things myself.

I thought about the old behavior, that forbid the import of libs when they were marked lazy. You can do it with depConstraints, but in that case you have to think the other way round - you can only define what is allowed, and not what is forbidden. Maybe an additional attribute next to onlyDependOnLibsWithTags is helpful in some situations (not sure, even often?), like notDependOnLibsWithTags. At the moment I only can think of tagging all libs with eager or lazy and then define { "sourceTag": "*", "onlyDependOnLibsWithTags": ["eager"] } to get the same results...

[github-actions]

This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.