Thank you.

@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).

@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

@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?

@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 ...

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.