missinglink VS sbt-missinglink

You can also use the upstream https://github.com/spotify/missinglink if you're using Maven instead of sbt.

There's been a recent release of missing-link with support for Mult-Release JARs and running analysis on multiple projects concurrently. More info here (applies not only to Scala/sbt, so it's worth linking it here): https://old.reddit.com/r/scala/comments/lxmi4w/sbtmissinglink_032_has_been_released_multirelease/

There are still some issues with MissingLink, like that it can't handle Multi-Release JARs (but that's being fixed I write) or that it uses thread-unsafe caches and so it can't be executed in parallel (and so it can take a long time to finish on big projects with many modules). But taken all together I swear by it. It has already saved us from runtime failures after deployment many times (it's easy to get incompatible versions when working on big projects with big number of dependencies). Instead, we get a red build in CI -- just anybody should expect for goodness sake when using a strongly-typed language like Scala.

And then there's sbt-missinglink, which can check that all the libraries that you're using in your application are compatible with each other (that one doesn't link to a missing class or method -- do you see? :) ). It prevents NoClassDefFoundError/NoSuchMethodError from happening at runtime.

sbt-missinglink can analyze all your projects concurrently. It can take a lot of memory, so you may want to limit the degree of concurrency via missinglinkConflictsTag

In our company, we've had good experience with sbt-missinglink. It's an sbt plugin made by Scala Center that wraps the MissingLink tool. It solves the problem the linked article describes, but does so in a more fundamental way. Instead of looking at versions of packages, it goes through all the class files and analyses possible "binary" conflicts.