How to resolve "Circular dependency" in NRWL

[kswaroop]

I am getting the below LINT error

"Circular dependency between "A(lib)" and "B(lib)" detected (nx-enforce-module-boundaries) tslint error"
Most of the issues are coming when a Service from one Library is used(imported) in another lib.

Can you please help how to resolve this issue

[czaplej]

U can't doing something like:
`
//LIB A
import libB from 'LIB_B'

//LIB B
import libA from 'LIB_A'
`
You create service "LIB_C" Which has methods that u used in LIB_A and LIB_B. LIB_C must be independent of LIB_A or LIB_B

[kswaroop]

Thanks, Yeah I am using in the same way, I have created a service 'LIB_XYZ which has the methods and I am using in other libraries, but still getting an error

[FrozenPandaz]

If you use nx dep-graph you should be able to see the circular dependency.

What @czaplej mentioned about creating a 3rd library works a lot of the time.

I wrote an initial doc in the wiki on resolving circular dependencies:

https://github.com/nrwl/nx/wiki/Resolving-Circular-Dependencies

Let me know if it helps.

[kkuriata]

Anyway, something happened that NX started posting linter errors? I didn't change anything in my project, "only" updated from 8 to 9 and linter started throwing circular dep errors (same nx-enforce-module-boundaries settings).

[czaplej]

I have similar errors that @kkuriata said. I have use 9.0.4 version of nx

[cngarkar]

I think @kkuriata is right. I'm also seeing the circular dependency issues after upgrading to 9.

[kswaroop]

Thanks, Yeah I am using in the same way, I have created a service 'LIB_XYZ which has the methods and I am using in other libraries, but still getting an error

I have manually updated the code by removing which has a circular dependency, It works fine now, Actually, all libraries are interrelated, so if one has dependency most of the other related are also failing

[snebjorn]

I getting false positives of nx-enforce-module-boundaries

I have this graph

Where each of the akita-ng-libraries have akita as a peerDependency

I also have a demo app which uses all of the above (remember peerDependencies) which causes the graph to look like this

and now I'm getting spammed with false nx-enforce-module-boundaries

Circular dependency between "akita-ng-entity-service" and "akita" detected
Circular dependency between "akita-ng-forms-manager" and "akita" detected
etc

please advice

[snebjorn]

Nevermind, I missed the arrow going from akita to the app :/

Now I'm not getting any nx-enforce-module-boundaries

Pretty cool tool - I must say

[dsebastien]

I'm facing difficulties understanding how to best structure my NX workspace in apps and libs to optimize build times and benefit from caching, considering an Angular + NGRX app.

As the starting point, I had one "web" app, composed of many major "features", each with its own (lazy-loaded) Angular module. Those modules were loaded lazily through the router, but also eagerly when a dependent Angular module needed it (e.g., if module X needs module Y, it has it in its imports).

As part of my current refactoring, I've extracted most of those features in separate libraries: one per major feature of the app, which I load lazily when needed.

Now, after fixing compilation issues, I remain with circular dependencies. My question is: what is your experience with splitting inter-dependent lazy-loaded Angular modules and what would be your recommendation?

Do you recommend splitting each feature in multiple libs (e.g., feature-x-core, feature-x-store, feature-x-dumb-components, feature-x-smart-components, ...)?

I've given this some thought and I don't see a clear path forward. For instance, if I consider the NGRX selectors of feature-x, then I can see that those rely on state types and selectors from feature-y.

One idea that I still have is extracting some parts (e.g., reducers & selectors) of the store for each feature and putting those in a shared "core" lib, but I'd still remain with the Angular module imports. Or should I just ignore the lint error in that case?

In our case I feel like keeping all of those features in the same NX lib is detrimental as it represents > 80% of the whole app.

[xmlking]

Hi difficult to find why I have circular dependency! don't see any dependency from core -> webapp in the code
https://github.com/xmlking/yeti

[snebjorn]

@xmlking