sbt-softwaremill

A sane set of common build settings.

Starting with 3.0.0, the plugins require sbt 2 (2.0.0 or newer) and JDK 17+. Projects still on sbt 1.x should use the 2.1.x series.

Usage

For each project where you'd like to use the build settings, add some or all of the following your project/plugins.sbt file:

addSbtPlugin("com.softwaremill.sbt-softwaremill" % "sbt-softwaremill-common" % "2.1.2")
addSbtPlugin("com.softwaremill.sbt-softwaremill" % "sbt-softwaremill-publish" % "2.1.2")
addSbtPlugin("com.softwaremill.sbt-softwaremill" % "sbt-softwaremill-browser-test-js" % "2.1.2")

Now you can add the appropriate settings in your build.sbt, e.g.:

import com.softwaremill.SbtSoftwareMillCommon.commonSmlBuildSettings

lazy val commonSettings = commonSmlBuildSettings ++ Seq(
  // your settings, which can override some of commonSmlBuildSettings
) 

Each dependency provides a choice of settings:

// common - compiler flags
import com.softwaremill.SbtSoftwareMillCommon.commonSmlBuildSettings
commonSmlBuildSettings

// publish
import com.softwaremill.Publish.ossPublishSettings
ossPublishSettings

// sets the jsenv to run scala.js tests in a headless chrome/firefox browser, using playwright
import com.softwaremill.SbtSoftwareMillBrowserTestJS.{browserChromeTestSettings, browserGeckoTestSettings}
browserChromeTestSettings
browserGeckoTestSettings 

sbt-softwaremill-common comes with:

• sbt-scalafmt
• sbt-tpolecat
• sbt-salad-days

sbt-softwaremill-publish comes with:

• sbt-ci-release

JS testing

The browser-test-js contains a fork of scala-js-env-playwright, which is built using Java 11.

Releasing your library

sbt-softwaremill-publish exposes a default configuration suitable for releasing open source libraries. The release process is broken into two steps:

1. local: sbt release. This sbt command prepares the next release: asks about the version, updates the version in the docs & readme, commits the changes and finally asks the user to push the changes. Your README.md, docs and doc directory will be parsed for "[organization]" %(%) "artifactId" % "someVersion" and that version value will be bumped.
2. remote: sbt ci-release. This sbt command should be run on GH actions, triggered when a new tag is pushed. It publishes the artifacts to sonatype, and invokes repository release.

To setup the remote part, follow the guide on sbt-ci-release. You can also take a look at this project's .github/workflows/ci.yml.

Releasing sbt-softwaremill

sbt-softwaremill release process is setup on GH Actions. This plugin uses itself to publish binaries to oss-sonatype.

Note for migrating from sbt-softwaremill 2.x series

The 3.x series supports only sbt 2. Moreover:

• the sbt-softwaremill-extra module is removed. Use Scala Steward for dependency updates; if you need sbt-updates or sbt-dependency-check, add them to your build directly.

Note for migrating from sbt-softwaremill 1.x series

You should remove version.sbt file as it's no longer used, and it may disrupt the release process. In the 2.x series the version is deduced from git tags and the current state using https://github.com/dwijnand/sbt-dynver.

Moreover, a number of bundled plugins are removed, which aren't available for Scala3 and would cause build problems