@nrwl/nx/enforce-module-boundaries allow AND/OR

Description

Allow AND/OR usage with tags.

Motivation

Currently the behavior is OR only, having AND would enable many more combinations to be possible without introducing new tags.

Suggested Implementation

Not so much implementation but an example api

"depConstraints": [
  {
    "sourceTag": "layer:ui",
    "onlyDependOnLibsWithTags": [{
      "tags": ["scope:admin", "layer:backend"],
      "operation": "AND"
    }]
  },
]

[meeroslav]

You don’t need to introduce the new tag or have new operator. You can simply split it into two constraints. The following behaves as AND:

"depConstraints": [
  {
    "sourceTag": "layer:ui",
    "onlyDependOnLibsWithTags": ["scope:admin"]
  },
  {
    "sourceTag": "layer:ui",
    "onlyDependOnLibsWithTags": ["layer:backend"]
  },
]

It does look like a bit of overhead, but the benefit is it gives you granular control and an overview of how tags are connected. Let me know if this works for your use case.

Note: The following logic is not implemented The other variant I see could be (notice inner array acting as AND):

"depConstraints": [
  {
    "sourceTag": "layer:ui",
    "onlyDependOnLibsWithTags": [["these:are", "joined:with:and"], "this:one:joins:with:or"]
  },
]

But I’m not convinced this wouldn’t end up being the foot gun.

[meeroslav]

I used non-framework for simplicity. In real application, you would never use such tag name. You could use architecture:x or something in those lines. But I hope you got the idea - if you bring new dimension (support for framework in your case) to the equation you need to make sure all the projects have an opinion (tag) on how they want to handle it, otherwise your rules will ban them.

We usually use scope:x for focus (vertical) segmentation and type:x for horizontal segmentation (apps, ui-features, libs, utils etc.). Usually all projects within one scope use the same framework, so there is no need for an explicit framework tag.