search

salesforce / rules_spring

Bazel rule for building Spring Boot apps as a deployable jar
BSD 3-Clause "New" or "Revised" License
224 stars 48 forks source link

Provide a dependency mutual exclusion check #150

Open plaird opened 2 years ago

plaird commented 2 years ago

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" ],
    ]
)