feat(lint): extend circular dependency check

[skydever]

The current check for circular dependencies is only evaluating direct dependencies between libs:

• A->B
• B->A

This PR extends this check to also recognize indirect circular dependencies:

• A->B
• B->C
• C->A

[vsavkin]

Thank you.

[mcblum]

@skydever possibly a dumb question, but is there a way to turn this off? because we're always importing from index.ts, we have a ton of warnings and linting errors where Module A --> Effects --> Module B --> ModuleBFeatureComponent --> Module A

Mostly I think we're seeing this because module A and B are sibling modules and have an interdependency (mostly on each other's actions).

[skydever]

@mcblum currently there is no way to turn this off (as far as I know the option to turn this check only off was not added since the pr), but you can turn off the rule nx-enforce-module-boundaries completely at tslint.json

but I think you should check your module/lib setup to get rid off the circular dependency / interdependency

[mcblum]

@skydever am I missing something obvious where sometimes you have two feature libs that depend on each other? Maybe our features are too small?

In this example there's a list of widgets and when a single widget is loaded, it has a bunch of sub-items that are loaded into a different feature. So the crossover is that the WidgetsEffects file has to import an action from libs/subitem/index.ts. Somewhere down the line in the code, one of the subitem components has to check to see if a widget was loaded or if a user refreshed on the edit sub-item screen. If there's a subitem, but no widget, then the sub-item component fires off a LoadWidget action which it gets from libs/widgets/index.ts.

Any suggestion of how to fix that?

[skydever]

@mcblum I think it does not matter how big a lib is, if they depend on each other you are not able to build them separately. e.g. if you decide to publish them on npm (you cant build A without B and the other way round, you are stuck). in my opinion this is the classic problem with circular deps, and the lint rule will warn you about that - even if it is possible with the current build mechanism of a nx workspace (like it is in your case), it does not feel "clean" ...

the easiest way would most likely be to merge both libs into one lib, but maybe creating a lib C that is doing the communication logic only is an option too. C can depend on A+B, that would not be a problem ...

[github-actions]

This pull request has already been merged/closed. If you experience issues related to these changes, please open a new issue referencing this pull request.