Git hooks in Scala projects — the easy way!

Photo by Mel Baylon on Unsplash

Quite a while ago I’ve written an article on creating git hooks for Scala projects. As noted back then, such hooks are useful in “our” language, since some “strict” settings cause an unnecessary waste of time when actively developing one’s code.

However, the solutions I’ve described, even in the most convenient case (using the pre-commit library), weren’t trivial and still required some work to set up.

Of course, the next logical step was to create a “sensible defaults” hook repository, so that the barrier to entry is reduced even further.

And that has been now accomplished :).

Introducing scala-pre-commit-hooks

The repo is HERE. Currently, the following hooks are available:

• sbt-fatal-warnings - turns on -Xfatal-warnings, runs a clean compilation on the given scope.
• sbt-unused-imports - as above, but also adds the "unused imports" warning.
• sbt-scalafmt - runs scalafmtCheckAll.
• sbt-wartremover - runs the wartremover plugin.

The nice thing about the setup is that you don’t need to clone anything, get into YAML-driven development, etc. It’s all ready to use.

You just need to:

1. Install pre-commit.
2. Add a relevant .pre-commit-config.yaml file to your repo.
3. Run pre-commit install .

(NOTE: since version 1.18.0, you can also set up per-repo auto-install through pre-commit init-templatedir )

Let’s say, for example, that you want to enable the unused imports check on commit and on push. You’d add the following file:

repos:
  - repo: https://github.com/softwaremill/scala-pre-commit-hooks
    rev: v0.3.0
    hooks:
     - id: sbt-unused-imports

and now, given that you’ve staged a file like this:

package com.softwaremill.githook_scala_demo

import scala.collection.immutable.List

class TestClass {

}

You will get a relevant error on commit:

/githook-scala-demo (master)> git commit -m “Testing”
Scala unused imports (+ fatal warnings)…………………………….Failed
hookid: sbt-unused-imports
[…]
githook-scala-demo/src/main/scala/com/softwaremill/githook_scala_demo/TestClas
[error] import scala.collection.immutable.List
[error] ^
[error] one error found
[error] (Compile / compileIncremental) Compilation failed

Want to limit the checks to pre-push? No problem, just add the relevant stages setting:

repos:
  - repo: https://github.com/softwaremill/scala-pre-commit-hooks
    rev: v0.3.0
    hooks:
     - id: sbt-unused-imports
       stages: [push]

This will now allow you to commit to your heart’s content — but will block a push with the same error(s).

Do you have integration tests maybe? Got you covered —go ahead and override the scope of the check:

repos:
  - repo: https://github.com/softwaremill/scala-pre-commit-hooks
    rev: v0.3.0
    hooks:
     - id: sbt-unused-imports
       args: ["--scope=it:compile"]

How about cross-compilation?

repos:
  - repo: https://github.com/softwaremill/scala-pre-commit-hooks
    rev: v0.3.0
    hooks:
     - id: sbt-unused-imports
       args: ["--scope=+compile"]

Or even multiple scopes?

repos:
  - repo: https://github.com/softwaremill/scala-pre-commit-hooks
    rev: v0.3.0
    hooks:
     - id: sbt-unused-imports
       args: ["--scope=test:compile;foo:compile;bar:compile"]

The scope parameter is supported by all hooks except for sbt-scalafmt (since that relies on the “All” task being configured correctly).

Optionally, the only other thing you need is to add any relevant (i.e. dependencies of the hooks you actively use) plugins to your project/plugins.sbt . If you lack those, the hooks will return a message pointing to the installation instructions.

This is a deliberate design decision— the most practical way of adding SBT plugins “automatically” would be to stage a modified version of plugins.sbt during the hook run, and then changing the file back. Such a workaround, however, breaks the Principle of Least Surprise. For example, if a hook fails for any reason, the user will be left with a “dirty” project state.

Fortunately, currently-supported plugins have sensible defaults which make adding them to a project “harmless”.

More documentation and notes (and the source code itself, for those interested) can be found at the project page. Happy coding in the New Year!