unused dependency detection is present in other build systems like pants.
Buck already does class usage tracking. We could add a flag to buck/target that enables strict dependency checking i.e if a dependency is unused due to no classes/resources from that dependency being used by the build target, we can fail the build after compilation and ask the user to remove such dependencies.
This can of check can be immensely useful to keep dependency graphs tight and prevent over-deping from happening
cc @styurin @ttsugriy
this would indeed be super useful. We have discussed this for similar reasons that you've discussed, but have not had time to work on it yet :(
Seems like https://github.com/facebook/buck/commit/2f6dd14fff74633c0ae06efbe3f2b2adca62f24a covers bit of this
hey @ttsugriy, do you know if there are any plans to support Kotlin unused deps, or if -c java.unused_dependencies_action=warn would take Kotlin into account?
Thanks!
Hello, @gugario! In theory since Kotlin libraries are using Java libraries, which do understand a concept of unused dependencies, under the hood, adding -c java.unused_dependencies_action=warn may be enough, but since we don't use Kotlin internally, I don't know how well it works in practice :( @kageiit may know more about how well it works for Kotlin :)
Please let us know how/if it works for you!
We need both directions, unused declared and used undeclared.
@alxn, what does "used undeclared" mean? Won't that result in a build error?
@gugario, right now this will not work for Kotlin as we don't currently have a way to track file usage in kotlinc. Once we do, this should work for Kotlin too. Check out https://youtrack.jetbrains.com/oauth?state=%2Fissue%2FKT-34253
https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html
Analyzes the dependencies of this project and determines which are:
1 used and declared;
2 used and undeclared;
3 unused and declared.
2 is when you use a transitive without explicitly declaring you are using it.
Ah, but in Buck all your dependencies have to be specified as first-order dependencies, so that case doesn't apply here