salesforce / salesforce/rules_spring

Provide a dependency mutual exclusion check

Open
#150 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Starlark
Stars
257
Forks
58
PR merge metrics
No merged PRs in 30d

Description

We have found internally that the springboot rule is a good enforcement chokepoint for catching errors in the dependency graph. the dupe class checker gets a lot of mileage and has caught a number of mistakes for us.

Another check we would like to have is fail if mutually exclusive dependencies are on the classpath (configurable in the workspace as per https://github.com/salesforce/rules_spring/issues/78). The reason is we have seen cases where the service owner ended up with mutually exclusive libraries in their spring boot jar. This is often due to transitive dependencies and thus hidden from the service owner.

For example, an internal API had a V1 and V2 versions, and a service should only use one of the other. But in one case both jars were in the service jar by mistake. While it didn't break anything, it surfaced a dependency graph error coming from poor hygiene.

Something like:

springboot(
...
    check_deps_mutualexclusive = [
        # case where external maven jars are brought in, and have different artifactIds
        [ "@maven//:com_acme_anvil_api_v1", "@maven//:com_acme_anvil_api_v2" ],

        # case where workspace packages are exclusive, for example persistence layers
        [ "//projects/acme/relationaldb", "//projects/acme/graphdb", "//projects/acme/csv" ],
    ]
)

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the springboot rule and the workspace configuration approach referenced in issue #78. Trace the existing dependency checks, then verify that configured Maven or workspace dependency groups fail when more than one member is present. Done means the rule reports the conflicting dependencies clearly and covers both example forms.

Written by the indexing model from the issue text.

Assessment

Tech stack
spring-boot
Domain
build-system
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.