Ability to allow eslint deps and !deps rules to accept wildcards (onlyDependOnLibsWithTags &| notDependOnLibsWithTags)

[un33k]

Description

A lint desired feature for big projects would be the ability to wildcard the tags within both the current onlyDependOnLibsWithTags and any future notDependOnLibsWithTags.

As you can see here, the granularity of the tags, and the ease of mix-&-match would be desired to make powerful rules with minimal efforts.

In the following example:

agx-* = framework, platform agnostic lib
ngx-* = angular framework dependant lib
nsx-* = nestjs framework dependant lib

// nx.json
"agx-dto": {
  "tags": ["scope:agx-data-low"]
},
"agx-store": {
  "tags": ["scope:agx-data-low"]
},
"ngx-store-service": {
  "tags": ["scope:ngx-data-mid"]
},
"ngx-member-service": {
  "tags": ["scope:ngx-data-high"]
},
"nsx-member": {
  "tags": ["scope:agx-data-low"]
},

In the above simulated example: (all scoped as data)

• agx-dto publishes the shape of data between the client & the api
• agx-store publishes a flat, state management system to store states
• ngx-store-service publishes the flat, state management system as an injectable service within Angular
• ngx-member-service: publishes member data
• nsx-member: has a graphql resolver to return member data (nestjs - server)

Where:

• agx-dto doesn't depend on anything and can be used in front/back(end) logics
• agx-store doesn't depend on anything and can be used in front/back(end) logics
• ngx-store-service depend on agx-dto and agx-store, within Angular
• ngx-member-service depends on ngx-store-service, agx-store and agx-dto, within Angular
• nxs-member depends on agx-dto within NestJs

If wildcard is supported the rules would look much simpler.

"depConstraints": [
 {
   "sourceTag": "scope:ngx-data-mid",
   "onlyDependOnLibsWithTags": ["scope:agx-data-*"]
 },
 ...
 {
   "sourceTag": "scope:ngx-data-high",
   "onlyDependOnLibsWithTags": ["scope:agx-data-*", "scope:ngx-data-*"]
 },
 ...
 {
   "sourceTag": "scope:nsx-data-high",
   "onlyDependOnLibsWithTags": ["scope:agx-data-*" , "scope:nsx-data-*"]
 },
 ...
 {
   "sourceTag": "scope:ngx-ui-low",
   "onlyDependOnLibsWithTags": ["scope:agx-data-*", "scope:ngx-data-*"]
 }
 {
   "sourceTag": "scope:ngx-ui-high",
   "onlyDependOnLibsWithTags": ["scope:agx-data-*", "scope:ngx-data-*", "scope:ngx-ui-*"]
 }
 ... 
 {
   "sourceTag": "scope:api-server",
   "onlyDependOnLibsWithTags": ["scope:agx-data-*",  "scope:nsx-data-*" ],
   "notDependOnLibsWithTags": ["scope:*-experimental-*" ]
 }
 ... 
 {
   "sourceTag": "scope:app-client",
   "onlyDependOnLibsWithTags": ["scope:agx-data-*", "scope:ngx-*" ],
   "notDependOnLibsWithTags": ["scope:*-experimental-*" ]
 }

The rules can be much more granular yet way more simpler, especially, if the future wildcard tags support a new notDependOnLibsWithTags. Especially if we can marry it to a flag called release | prod, to let's say prevent experimental
feature dependancies during production builds. (thinking out loud here!)

Motivation

My experience with very large projects in the healthcare / insurance industries, where some 200+ devs continuously raised PRs without proper import restrictions or rules, shines light on the possible benefit gain, from a more granular tags (scope, types ..etc) system. But with granularity comes complexity, and with complexity come confusions. This feature request is to enable architects layout the rules properly, and for those who step in to maintain it, to understand it easily.

Suggested Implementation

What we need is first to enable wildcard for tags, as per the simulated examples above, then spice it up with the introduction of a negative rule, something like notDependOnLibsWithTags.

Alternate Implementations

To use it as it is now, and tag anything data related as data, no matter how high or low within the thick data-layer a lib falls.

Ref: Fullerstack

[github-actions]

This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs.
If we missed this issue please reply to keep it active.
Thanks for being a part of the Nx community! 🙏

[github-actions]

This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.