After working in several Scala projects you are likely to end up with a minimal seed (kind of a project template) that you'll use whenever you start a new project.
Part of this seed would include some general-purpose sbt plugins, and these are the ones I'd pick.
It's always ideal to have your dependencies updated to the latest release. To automate that, sbt-updates can check maven repositories for dependency updates on your project dependencies (there is also a limited support for Ivy repositories hosted on BinTray).
dependencyUpdates command displays the currently available updates:
> dependencyUpdates Found 14 dependency updates for project com.typesafe:config : 1.3.0 -> 1.3.1 ch.qos.logback:logback-classic : 1.1.10 -> 1.2.1 org.slf4j:jcl-over-slf4j : 1.7.22 -> 1.7.23 com.typesafe.akka:akka-slf4j : 2.4.16 -> 2.4.17 com.typesafe.akka:akka-actor : 184.108.40.206 -> 2.4.17 com.typesafe.akka:akka-http-core : 220.127.116.11 -> 10.0.3 com.typesafe.akka:akka-stream : 18.104.22.168 -> 2.4.17 com.lightbend.akka:akka-stream-alpakka-sqs : 0.5 -> 0.6 de.heikoseeberger:akka-http-circe : 1.11.0 -> 1.12.0 org.scala-lang.modules:scala-parser-combinators : 1.0.4 -> 1.0.5 com.h2database:h2 : 1.4.192 -> 1.4.193 com.zaxxer:HikariCP : 2.5.1 -> 2.6.0 org.scalatest:scalatest : 3.0.1 -> 3.2.0-SNAP4 com.typesafe.akka:akka-stream-testkit : 2.4.16 -> 2.4.17
Every now and then you might need to inspect the transitive dependencies in your project, especially when there are clashes and evictions. sbt-dependency-graph creates a dependency graph including that information.
dependencyGraph command will output all the dependencies in an ASCII tree graph:
> dependencyGraph ... +-com.typesafe.akka:akka-stream_2.12:2.4.16 [S] +-com.typesafe.akka:akka-actor_2.12:2.4.16 [S] | +-com.typesafe:config:1.3.0 (evicted by: 1.3.1) | +-com.typesafe:config:1.3.1 | +-org.scala-lang.modules:scala-java8-compat_2.12:0.8.0 [S] | +-com.typesafe:ssl-config-core_2.12:0.2.1 [S] | +-com.typesafe:config:1.2.0 (evicted by: 1.3.1) | +-com.typesafe:config:1.3.1 | +-org.scala-lang.modules:scala-parser-combinators_2.12:1.0.4 [S] | +-org.reactivestreams:reactive-streams:1.0.0 ...
No matter what your formatting conventions are, avoid relying on manual enforcement is paramount. The main feature of sbt-scalariform is that it automatically formats the source code on the specified build stages, using Scalariform.
Even if the source code is automatically formatted, having a static style checker like scalastyle-sbt-plugin allows to generate a report to visually inspect the analysis.
In addition to the standard library warnings, sbt-wartremover adds more validations during the compile stage to enforce better coding conventions such as usage of
asInstanceOf or non-final case classes, for instance. Here's the list of all supported validations.
In order to have a summary of the amount of code covered by unit tests, sbt-scoverage provides code coverage reports in HTML and XML:
sbt-native-packager lets you generate application packages in native formats. It supports universal
rpm for Debian/RHEL,
dmg for OSX,
msi for Windows and, drumroll,
In your CI jobs you can take advantage of most of these sbt plugins to generate everything you need in one go:
sbt clean compile coverage test scalastyle coverageReport coverageOff docker:publish
This sequence of sbt commands will:
Do you regularly use any other sbt plugins? Please share!
Would you like to leave a comment? Since this blog is hosted on GitHub Pages there's no straightforward way to do so.
Instead, you can add a comment in this GitHub issue. If you'd like to see it here, refresh this page after posting the comment.