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.
Keeping all your dependencies under control
sbt-updates
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).
Running the 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 : 2.4.11.1 -> 2.4.17
com.typesafe.akka:akka-http-core : 2.4.11.1 -> 10.0.3
com.typesafe.akka:akka-stream : 2.4.11.1 -> 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
sbt-dependency-graph
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.
Running the 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
...
Keeping the code clean
sbt-scalariform
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.
scalastyle-sbt-plugin
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.
sbt-wartremover
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 null and asInstanceOf or non-final case classes, for instance. Here's the list of all supported validations.
sbt-scoverage
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:
Preparing to release
sbt-native-packager
sbt-native-packager lets you generate application packages in native formats. It supports universal zip, tar.gz and xz archives, deb and rpm for Debian/RHEL, dmg for OSX, msi for Windows and, drumroll, docker images.
Usage
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:
- Clean the generated target
- Compile
- Enable scoverage to instrument the code
- Run the tests
- Generate the scalastyle report
- Generate the code coverage report
- Disable scoverage to remove instrumentation (this step is mandatory if there are further build steps, since it would use instrumented code otherwise)
- Build and publish the corresponding docker image
Do you regularly use any other sbt plugins? Please share!
Comments
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.