search term:

sbt 1.4.0

Hi everyone. On behalf of the sbt project, I am happy to announce sbt 1.4.0. This is the fourth feature release of sbt 1.x, a binary compatible release focusing on new features. sbt 1.x is released under Semantic Versioning, and the plugins are expected to work throughout the 1.x series.

The headline features of sbt 1.4.0 are:

How to upgrade

Download the official sbt launcher from SDKMAN or download from This installer includes the sbtn binary.

In addition, the sbt version used for your build is upgraded by putting the following in project/


This mechanism allows that sbt 1.4.0 is used only for the builds that you want.

Build server protocol (BSP) support

sbt 1.4.0 adds build server protocol (BSP) support, contributed by Scala Center. Main implementation was done by Adrien Piquerez (@adpi2) based on @eed3si9n’s prototype.

When sbt 1.4.0 starts, it will create a file named .bsp/sbt.json containing a machine-readable instruction on how to run sbt -bsp, which is a command line program that uses standard input and output to communicate to sbt server using build server protocol.

How to import to IntelliJ using BSP

  1. Start sbt in a terminal
  2. Open IntelliJ IDEA 2020.1.2 or later
  3. Select “Open or import”, and select “BSP Project”

How to import to VS Code + Metals

  1. Delete existing .bsp, .metals, .bloop directories if any
  2. Open VS Code in the working directory
  3. Ignore the prompt to import the project
  4. Start sbt -Dsbt.semanticdb=true in the Terminal tab. Wait till it displays “sbt server started”
  5. Navigate to Metals view, and select “Restart build server”
  6. Type compile into the sbt session to generate SemanticDB files

#5538/#5443 by @adpi2

Native thin client

sbt 1.4.0 adds an official native thin client called sbtn that supports all tasks. If you’re using the official sbt launcher 1.4.0 and not the knockoff kind you can use --client option to run the native thin client:

$ sbt --client compile
$ sbt --client shutdown

The native thin client will run sbt (server) as a daemon, which avoids the JVM spinup and loading time for the second call onwards. This could an option if you would like to use sbt from the system shell such as Zsh and Fish.

Remember to call sbt --client shutdown when you’re done! If you want to enable this via an environment variable you can set SBT_NATIVE_CLIENT to true. sbtn binary files are also available from

#5620 by @eatkins

ThisBuild / versionScheme

sbt 1.4.0 adds a new setting called ThisBuild / versionScheme to track version scheme of the build:

ThisBuild / versionScheme := Some("early-semver")

The supported values are "early-semver", "pvp", and "semver-spec". sbt will include this information into pom.xml and ivy.xml as a property. In addition, sbt 1.4.0 will use the information to take the guessing out of eviction warning when this information is available. #5724 by @eed3si9n

VirtualFile + RemoteCache

sbt 1.4.0 / Zinc 1.4.0 virtualizes the file paths tracked during incremental compilation. The benefit for this that the state of incremental compilation can shared across different machines, as long as ThisBuild / rootPaths are enumerated beforehand.

To demonstrate this, we’ve also added experimental cached compilation feature to sbt. All you need is the following setting:

ThisBuild / pushRemoteCacheTo := Some(MavenCache("local-cache", file("/tmp/remote-cache")))

Then from machine 1, call pushRemoteCache. This will publish the *.class and Zinc Analysis artifacts to the location. Next, from machine 2, call pullRemoteCache.

zinc#712/#5417 by @eed3si9n

Build linting

On start up, sbt 1.4.0 checks for unused settings/tasks. Because most settings are on the intermediary to other settings/tasks, they are included into the linting by default. The notable exceptions are settings used exclusively by a command. To opt-out, you can either append it to Global / excludeLintKeys or set the rank to invisible.

#5153 by @eed3si9n

Conditional task

sbt 1.4.0 adds support for conditional task (or Selective task), which is a new kind of task automatically created when Def.task { ... } consists of an if-expression:

bar := {
  if (number.value < 0) negAction.value
  else if (number.value == 0) zeroAction.value
  else posAction.value

Unlike the regular (Applicative) task composition, conditional tasks delays the evaluation of then-clause and else-clause as naturally expected of an if-expression. This is already possible with Def.taskDyn { ... }, but unlike dynamic tasks, conditional task works with inspect command. See Selective functor for sbt for more details. #5558 by @eed3si9n

Incremental build pipelining

sbt 1.4.0 adds experimental incremental build pipelining. To enable build pipelining for the build:

ThisBuild / usePipelining := true

To opt-out of creating an early output for some of the subprojects:

exportPipelining := false

#5703 by @eed3si9n

sbt-dependency-graph is in-sourced

sbt 1.4.0 brings in Johannes Rudolph’s sbt-dependency-graph plugin into the code base. Since it injects many tasks per subprojects, the plugin is split into two parts:


Fixes with compatibility implications

Other updates


sbt 1.4.0 was brought to you by 34 contributors. Ethan Atkins, Eugene Yokota (eed3si9n), Johannes Rudolph, Dale Wijnand, Adrien Piquerez, Jason Zaugg, Arnout Engelen, Josh Soref, Guillaume Martres, Maksim Ochenashko, Anil Kumar Myla, Brice Jaglin, Claudio Bley, João Ferreira, Steve Waldman, frosforever, Alex Zolotko, Heikki Vesalainen, Ismael Juma, Stephane Landelle, Jannik Theiß, izharahmd, lloydmeta, Alexandre Archambault, Eric Peters, Erwan Queffelec, Kenji Yoshida (xuwei-k), Martin Duhem, Olafur Pall Geirsson, Renato Cavalcanti, Vincent PERICART, nigredo-tori. Thanks!

Thanks to everyone who’s helped improve sbt and Zinc 1 by using them, reporting bugs, improving our documentation, porting builds, porting plugins, and submitting and reviewing pull requests.

For anyone interested in helping sbt, there are many avenues for you to help, depending on your interest. If you’re interested, Contributing, “help wanted”, “good first issue” are good starting points.

Note to plugin authors

If you build and publish a plugin using sbt 1.4.0, your users will also be forced to upgrade to sbt 1.4.0 immediately. To prevent this you can cross build your plugin against sbt 1.2.8 (while using sbt 1.4.0) as follows:

pluginCrossBuild / sbtVersion := "1.2.8"


To test sbt server manually, make sure to have an sbt session running, and start sbt -bsp in another termnial. And paste the following in:

{ "jsonrpc": "2.0", "id": 1, "method": "build/initialize", "params": { "displayName": "foo", "version": "1.0.0", "bspVersion": "2.0.0-M5", "rootUri": "file:///tmp/hello", "capabilities": { "languageIds": ["scala"] } } }

Then enter \r\n (type Enter, Ctrl-J for zsh). This should return:

Content-Length: 200
Content-Type: application/vscode-jsonrpc; charset=utf-8