Can't implement cross-domain 2-dimensional checks due to current design

[sdurnov]

Is your feature request related to a problem? Please describe.
I'm submitting this feature request because I found myself unable to set up NX enforce module boundaries and Sheriff to do 2-dimensional check on relations between my project's libraries.
I have a project, which kinda follows strategic design described in many Angular Architects articles.
I use NX, where I have domains, subdomains, and domain libraries of following types:

• api
• data-access
• domain
• data (when data-access is combined together with domain for simplicity)
• feature
• shell
• ui
• util

Each domain might have libraries of some or all of the types above.

I have restrictions on relationships between libraries within the domain, and that is a functionality which is possible implement with NX enforce module boundaries and Sheriff.

But I also gotta have separate rules for libraries relation between domains. I need to make sure any library in domain A can use API library from domain B, but can't use API library from its own domain.
I also want to let any library from any (or certain) domains use any library from shared domain.
For example, in shared/ I have Auth subdomain, and other libs might only use auth/api lib, but also in shared I have UI library, which can be used by certain libraries in other domains, etc.

Anyway, as you see, those restrictions can't be described by what currently NX and Sherif allow to do within 1 rule.

Describe the solution you'd like
I would like to be able to do few things:

• define dep rule this way or similar (sorry, this syntax is ugly and dumb, but I hope you'll get the point):

tags: 'type:api && domain:<domain>': '(type:data or type:data-access or type:domain or type:feature or type:ui or type:util) and domain:<domain>',
tags: '(type:data or type:data-access) && domain:<domain>': '(type:domain or type:util) and domain:<domain>',
tags: 'type:domain && domain:<domain>': '!domain:<domain>',
tags: 'type:feature && domain:<domain>': '!type:api and !type:shell and domain:<domain>',
tags: 'type:shell && domain:<domain>': '!type:api and domain:<domain>',
tags: 'type:ui && domain:<domain>': '(type:data or type:domain or type:util) and domain:<domain>',
tags: 'type:util && domain:<domain>': 'type:domain && domain:<domain>',
//restrictions between domains
tags: 'type:app': 'type:api or type:shell or ((type:ui or type:util or type:domain) && domain:shared)',
tags: '!type:app && domain:<domain> && !domain:shared': 'type:api && !domain:<domain>',
tags: '!type:app && !domain:shared': '(type:api or type:ui or type:domain or type:util) && domain:shared',
tags: 'domain:shared': 'domain:shared:<subdomain> or domain:shared',
tags: 'domain:shared:<subdomain>': 'domain:shared:<subdomain>'

• or just give user a single function instead of all rules, maybe together with some types and helper functions to write rules instead of direct operations with arrays and strings

(from: string | string[], to: string | string[]): boolean => {
    if (...) {
        ...
    }
}

Describe alternatives you've considered
I've checked first source code for NX rule hoping maybe I can do a quick modification to allow to define some logical expressions instead of single tag or hard combination of tags, and maybe to combine rules during checking, not cancelling previous rule with the next one, but I gave up the idea for now, hoping maybe that Sherif has something not obvious to cover my needs, or planned it for the near future

Additional context
Here is a small part of my project graph in NX. it shows job applications domain, which has libs of type:shell, type:data-access, type:domain, type:util, several type:feature (though type:shell one is named incorrectly as feature-wizard-shell). There's also shared libs, where we have plain type:ui and type:util libs, as well as a whole auth subdomain with its set of libs resembling a typical domain. And here you can see I forbidden link - someone referenced auth-feature-auth-v3 directly, instead of reexporting something he needed via auth-api lib.
There are also few connections going ouside to the app, which is cut off the screenshot

[rainerhahnekamp]

Thanks for adding the issue with detailed context. We've been discussing a few options on that topic internally for some time.

I suggest providing a DSL that lets you programmatically implement the rules however you want. So that would be in the end a "catch all" rule depRules: {'*': () => ruleLogic} with additional utility functions.

Give me a few days to think about it, and maybe we can come up with some specifications.

/cc @wolfmanfx, can you also comment on that and what impact such a DSL would have on the UI?

[wolfmanfx]

@rainerhahnekamp The ui would render it (or should) but you could not alter the tags and so on. But in the long term we should think about an declarative approach combined with an general purpose DSL:

  {
      from: 'type:app',
      allow:
        'type:api OR type:shell OR (domain:shared AND (type:ui OR type:util OR type:domain))',
    },
    {
      from: '!type:app AND domain:<d> AND !domain:shared',
      allow: 'type:api AND !domain:<d>',
    },

We would need an grammar which supports AND/OR/NOT/! and so on but than we would not rely on typescript.

[rainerhahnekamp]

Hey, I am not sure about the flexibility of the DSL and if it kind of stands for the amount of work, we have to put in.

On the other side if we are saying, we are just providing a function and users can implement whatever they want, then there might be the constraint for the UI in that sense, that the UI can't generate the code. But it will work in the different direction namely that users can write code and the UI will show the impact of those rules in a visual way...

[wolfmanfx]

Sure I see at bit more layered - with the DSL you could do expressive logic which the UI can expressive somehow.
If there is still some flexibility needed than you could go a level deeper and provide an custom depRule as an function (plugin).

[sdurnov]

Hey, I am not sure about the flexibility of the DSL and if it kind of stands for the amount of work, we have to put in.

On the other side if we are saying, we are just providing a function and users can implement whatever they want, then there might be the constraint for the UI in that sense, that the UI can't generate the code. But it will work in the different direction namely that users can write code and the UI will show the impact of those rules in a visual way...

Given that this level of functionality is currently completely unavailable, I'd be happy if it will appear initially without eslint integration. I guess I could just run a standalone Sheriff binary during CI/CD and it would do the work.

[rainerhahnekamp]

Yeah, we won't wait for the UI to enable that option for you.

@sdurnov do you maybe want to implement it on your own? In the end it is just finding that function and add fromTags, toTags.

[sdurnov]

Yeah, we won't wait for the UI to enable that option for you.

@sdurnov do you maybe want to implement it on your own? In the end it is just finding that function and add fromTags, toTags.

I might try if nobody pick this up in coming weeks

[sdurnov]

Yeah, we won't wait for the UI to enable that option for you.

@sdurnov do you maybe want to implement it on your own? In the end it is just finding that function and add fromTags, toTags.

Actually, working on it. Seems I got it functional. But I guess I also need to add some tests and docs, right?

[rainerhahnekamp]

@sdurnov

Yes at least for tests. Documentation is something that I can come up with as well.

Do you want to push a Draft PR?

[sdurnov]

@sdurnov

Yes at least for tests. Documentation is something that I can come up with as well.

Do you want to push a Draft PR?

yep, pushed a very basic draft, let's move further from there