autonomousapps / autonomousapps/dependency-analysis-gradle-plugin

Warn users when excluding used-transitives that they can break their build when removing unused dependencies

Open
#686 0 comments 0 reactions 0 assignees View on GitHub
enhancement sponsorable
Dominant language
Kotlin
Stars
2.2k
Forks
158
Avg merge
16h 25m
Merged PRs (30d)
46

Description

**Is your feature request related to a problem? Please describe.**

When users set the severity to `'ignore'` for `onUsedTransitiveDependencies`, that is a very "dumb", coarse-grained filter. It doesn't take into account that this can easily lead to broken builds when combined with removing unused dependencies. Consider this situation:
```
Project -> A -(api)-> B
```
Our project declares a dependency on `A`, which in turn has an `api` dependency on `B`. Our project uses `B` but does not use `A`. Therefore, the plugin will suggest removing `A` and adding `B`. However, if the user has filtered out all used transitive dependencies, then the only advice they will see is that they should remove `A`. While this is true, strictly speaking, if `A` is the only path to `B` in the dependency graph, then removing `A` also removes `B`, which can break the build. (Users then think this plugin has a bug ;_;)

**Describe the solution you'd like**

Some options include:
1. Coarse-grained warning summarizing the issue as described above. (Easiest to implement)
2. Fine-grained warning when a specific issue of this type has been detected.
3. Adjust the advise to either filter out the "unused" advice or override the "ignore" filter when this situation has been detected.

**Additional context**
People frequently think (incorrectly) the plugin has a bug when this situation arises.

Contributor guide

Open the contributing guide

Research direction

No files or tests are named. Start by tracing the onUsedTransitiveDependencies severity filtering and the unused-dependency advice for the described A→B api-dependency graph; done means users receive a warning or adjusted advice when ignoring used transitives could break the build.

Written by the indexing model from the issue text.

Assessment

Tech stack
kotlin
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.