Nx: imports of lazy-loaded libraries are forbidden due to name collision

[FallenRiteMonk]

I have a lib called 'order', which is lazy-loaded, and a lib called 'oder-api', which isn't lazy loaded.

TSLint gives me the following error on a import of the OrderApiModule (from 'order-api').
[tslint] imports of lazy-loaded libraries are forbidden (nx-enforce-module-boundaries)

As far as I could figure out there is some name collision with the 'order' lib, because if I rename the 'order-api' libs folder to something like 'apiorder', the error is not displayed anymore. For renaming it 'orderapi' (without dash) I also get the error.

Version info:
"@nrwl/nx": "0.7.4",
"tslint": "5.9.1",

[ThomasBurleson]

@FallenRiteMonk - can you test with the latest 0.8.0 release ?

[FallenRiteMonk]

@ThomasBurleson event with 0.8.0 I get the same error message.

Furthermore I noticed that by installing 0.8.0 one gets the following message displayed:

 postinstall <PROJECT_PATH>
> nx migrate check

-----------------------------------------------------------------------------
-------------------------------IMPORTANT!!!----------------------------------
-----------------------------------------------------------------------------
Run "npm run update" to run the following migrations:
- 20180225-switch-to-cli17
Switch to Angular CLI 1.7
-----------------------------------------------------------------------------
- 20180227-cleanup-scripts
Add update, update:skip, update:check scripts
-----------------------------------------------------------------------------
Or run "npm run update:skip" to set the latestMigration property
in .angular-cli.json to: "20180227-cleanup-scripts".
npm WARN [email protected] requires a peer of @ngrx/store@^4.0.0 but none is installed. You must install peer dependencies yourself.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

updated 2 packages in 17.257s

This is a bit misleading because one hast to run npm run nx-migrate first, so that the 'nx-migrate' script gets renamed to 'update'.

[dereklin]

I am using 0.8.0
It seems like all relative imports are in violation of "nx-enforce-module-boundaries":

[tslint] library imports must start with @mono/ (nx-enforce-module-boundaries)

For example, in one of my spec files, this raises the violation:

import { SomeService } from './some.service';

I am turning off "nx-enforce-module-boundaries" for now

[skydever]

@dereklin are you using windows? does this pr fix your situation? here is the JS file you can replace at /node_modules/@nrwl/schematics/src/tslint/nxEnforceModuleBoundariesRule.js

@FallenRiteMonk wanted to check your issue too, but somehow this.npmScope at this line is always undefined (simply using console.log there, in the transpiled JS file under node_modules) at my side, because of that line maybe, it does not get initialised? or my setup is somehow broken at the moment (will look again later) ... wanted to do just this:

const lazyLoaded = lazyLoad.filter(l => {
  const lazyImp = `@${this.npmScope}/${l}`;
  return imp === lazyImp || imp.startsWith(`${lazyImp}/`);
})[0];

maybe you can try this in the JS file of node_modules? somehow like this:

var lazyLoaded = lazyLoad.filter(function (l) {
  var lazyImp = "@" + _this.npmScope + "/" + l;
  return (imp === lazyImp || imp.startsWith(lazyImp + "/"));
})[0];

[dereklin]

@skydever Yes. I am using Windows 7. The pull request did most of the cleaning. I still have some issues. I have a angular playground app, there I have a sandbox that does this:

import { SomeComponent } from '../../../../apps/app1/src/app/basket/Some.component';

I am importing from apps, not libs, and yet it's complaining the same things:

[tslint] library imports must start with @mono/ (nx-enforce-module-boundaries)

[FallenRiteMonk]

@skydever I don't have the time this weekend, but I'll give it a try as soon as possible next week.

[spiotr12]

+1
it would be nice to be able to control individual rules (if that's possible)

[skydever]

@FallenRiteMonk I updated the quick fix file, your use case should be covered now. I will add that to the PR #290. You can try when you have the time for it ... (my setup was broken yesterday, the workspace I used was at 0.5.4 [switched to another notebook, was not up to date] - created a new workspace today, everything is fine now)

@dereklin in my opinion it's complaining as expected. your import should look like @mono/lib if you import from a lib of your workspace (and you should export the public stuff from that lib at index.ts of the lib to be able to do so). more important, you are importing from an app - and the lint rule tries to prevent that too, on purpose. so your situation is special (not quite sure what exactly you are doing) - you can add ../../../../apps/app1/src/app/basket/Some.component to the allow section of tslint.json at the rule nx-enforce-module-boundaries to get rid of the lint error, or better create a lib that contains SomeComponent and import that into both your apps (or libs), as expected for use cases like this. one thing I agree, the lint error should contain imports of apps are forbidden to be more clear, instead of library imports - maybe I can add that to the PR too, I will try ...

@spiotr12 what kind of individual rules are you talking about? just wondering, interested in your thoughts. you can allow any import using the allow section in tslint.json, that is currently possible for what I know ...

[dereklin]

@skydever I agree my use case is special. I am writing a single Angular Playground (http://www.angularplayground.it/) app to test all the components (in apps and libs). I'll just disable the rules in my Angular Playground sandboxes for now.

Thanks for your time.

[FallenRiteMonk]

@skydever just tested your quick-fix and it seems to be working just fine!

Any idea on when we are going to see this merged?

[skydever]

@FallenRiteMonk great to hear!

I try to add some tests, I hope the pr will get merged then ...

[spiotr12]

@skydever
I meant that there are 4 rules and I wanted to turn off e.g. "library imports must start with @.../" but keep the other 3 rule. setting "nx-enforce-module-boundaries": [true] turns all of them off. I do not know how to use allow: [] could you briefly explain how to use it? thanks! 😄

[skydever]

with allow you can set a list of import paths that are allowed no matter where you import from it (eg. allow: ["../../libs/mylib/some.component", "../../libs/my-other-lib/other.component"]). it is a white list of allowed import paths.

allowing globs here would be nice, but at the moment it has to match exactly...

[skydever]

...turning off just some of the rules sounds interesting too

[spiotr12]

Thanks! 😄

[vsavkin]

PR 290 was merged, and the issue was fixed.

Closing this issue.