A sane set of common build settings.

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.0.21")
addSbtPlugin("com.softwaremill.sbt-softwaremill" % "sbt-softwaremill-publish" % "2.0.21")
addSbtPlugin("com.softwaremill.sbt-softwaremill" % "sbt-softwaremill-extra" % "2.0.21")
addSbtPlugin("com.softwaremill.sbt-softwaremill" % "sbt-softwaremill-browser-test-js" % "2.0.21")

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

// extra - use all or choose
lazy val extraSmlBuildSettings =
  dependencyUpdatesSettings ++  // check dependency updates on startup (max once per 12h)
  dependencyCheckSettings

// downloads the appropriate chrome/gecko driver for testing scala.js using scalajs-env-selenium and sets the jsenv
import com.softwaremill.SbtSoftwareMillBrowserTestJS.{browserChromeTestSettings, browserGeckoTestSettings}
browserChromeTestSettings
browserGeckoTestSettings 

sbt-softwaremill-common comes with:

• sbt-scalafmt
• sbt-tpolecat

sbt-softwaremill-publish comes with:

• sbt-ci-release

sbt-softwaremill-extra comes with:

• sbt-updates
• sbt-dependency-check

By default, the plugins use the new s01.oss.sonatype.org host for releasing to Sonatype. If your project isn't yet migrated, you'll need to add the following to your root project settings:

sonatypeCredentialHost := "oss.sonatype.org"

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.

You might need to explicitly set the sonatype profile name:

val commonSettings = ossPublishSettings ++ Seq(
  sonatypeProfileName := "com.example"
)

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

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