Update sbt to 2.0.0#488
Conversation
📝 WalkthroughWalkthroughThe ChangesSBT Version Upgrade
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~1 minute Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@project/build.properties`:
- Line 1: The sbt version upgrade to 2.0.0 in build.properties is incompatible
with two plugins in the project's build configuration: sbt-coveralls 1.3.15 is
sbt 1.x-only with no sbt 2.0 release, and sbt-mergify-github-actions 0.9.0 lacks
explicit sbt 2.0 support. Before merging this change, locate and update these
plugin versions in the build configuration (likely in project/plugins.sbt or
similar) to sbt 2.0-compatible versions, or replace them with compatible
alternatives. The sbt-scoverage 2.4.4 and sbt-ci-release 1.11.2 plugins are
already compatible and require no changes. If compatible versions are
unavailable, revert the sbt version back to 1.12.12.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 40d87301-2602-4ec1-9178-3f389e7df8e7
📒 Files selected for processing (1)
project/build.properties
| @@ -1 +1 @@ | |||
| sbt.version=1.12.12 | |||
| sbt.version=2.0.0 | |||
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Verify sbt plugin compatibility with sbt 2.0.0
# Test: Check if plugins in project/plugins.sbt declare sbt 2.0.0 support
rg -A 5 'addSbtPlugin' project/plugins.sbt
# Test: Search codebase for references to sbt 1.x specific APIs or syntax (e.g., ThisBuild, old scoping syntax)
echo "=== Checking for potential sbt 1.x specific patterns ==="
rg 'ThisBuild|inThisBuild|in ThisBuild' --type scala || echo "No ThisBuild references found"
# Test: Check for .sbt files that might use old 0.13 syntax (curly-brace syntax)
echo "=== Checking for potential sbt 0.13 syntax ==="
find . -name '*.sbt' -exec grep -l '{' {} \; | head -5 || echo "No potential 0.13 syntax found"Repository: nafg/slick-migration-api
Length of output: 492
🏁 Script executed:
# Check the content of ci.sbt to see what syntax is used
cat -n ci.sbtRepository: nafg/slick-migration-api
Length of output: 1844
🏁 Script executed:
# Check the content of build.sbt to understand the inThisBuild usage
head -30 build.sbtRepository: nafg/slick-migration-api
Length of output: 1403
🌐 Web query:
sbt-scoverage 2.4.4 sbt 2.0.0 compatibility
💡 Result:
Yes, sbt-scoverage version 2.4.4 is compatible with sbt 2.0.0 [1]. The official Scala Index explicitly lists compatibility for sbt-scoverage 2.4.4 with sbt 2.x [1]. The plugin is distributed with cross-build support for sbt 2.0.0, and you can add it to your project's plugins by using the standard plugin dependency declaration: addSbtPlugin("org.scoverage" % "sbt-scoverage" % "2.4.4") Historical releases of sbt-scoverage had been adding support for sbt 2.0.0 milestone and release candidate versions leading up to the final sbt 2.0.0 release [2], confirming a managed transition to support the latest major version of sbt.
Citations:
- 1: https://index.scala-lang.org/scoverage/sbt-scoverage/artifacts/sbt-scoverage/2.4.4?binary-version=_sbt2_3
- 2: https://github.com/scoverage/sbt-scoverage/releases
🌐 Web query:
sbt-coveralls 1.3.15 sbt 2.0 compatibility
💡 Result:
As of June 2026, sbt-coveralls version 1.3.15 is not natively compatible with sbt 2.0. Sbt 2.0 introduced significant breaking changes, including a new plugin publishing format (using the _sbt2_3 suffix) and a move to Scala 3.x for build definitions [1]. Current metadata for sbt-coveralls 1.3.15 indicates it is published for sbt 1.x [2], and there is no evidence of an sbt 2.0-specific release for this plugin. While the related plugin sbt-scoverage has actively incorporated support for sbt 2.0 (e.g., versions starting from 2.4.x) [3][4], sbt-coveralls remains at version 1.3.15, last updated in January 2025 [5][6]. Users attempting to use sbt-coveralls in an sbt 2.0 build environment will likely encounter compatibility errors due to these structural changes in the sbt plugin ecosystem [1].
Citations:
- 1: https://www.scala-sbt.org/2.x/docs/en/changes/sbt-2.0-change-summary.html
- 2: https://index.scala-lang.org/scoverage/sbt-coveralls/artifacts/sbt-coveralls
- 3: https://index.scala-lang.org/scoverage/sbt-scoverage/artifacts/sbt-scoverage?stableOnly=true
- 4: https://github.com/scoverage/sbt-scoverage/releases/tag/v2.4.0
- 5: https://index.scala-lang.org/scoverage/sbt-coveralls/artifacts/sbt-coveralls/1.3.15
- 6: https://github.com/scoverage/sbt-coveralls
🌐 Web query:
sbt-ci-release 1.11.2 sbt 2.0 compatibility
💡 Result:
sbt-ci-release version 1.11.2 is fully compatible with sbt 2.x [1][2]. The plugin is cross-published to support both sbt 1.x and sbt 2.x ecosystems [1][3]. When using version 1.11.2, you can use the standard dependency declaration in your project: addSbtPlugin("com.github.sbt" % "sbt-ci-release" % "1.11.2") [2] The plugin maintains support for both major versions, which is particularly useful for projects performing migrations or back-publishing during the sbt 2.x transition [4][5]. Additionally, sbt-ci-release 1.11.x and later includes support for the Central Portal publishing requirements, which are necessary for modern sbt releases [4][6].
Citations:
- 1: https://github.com/sbt/sbt-ci-release/releases/tag/v1.11.2
- 2: https://index.scala-lang.org/sbt/sbt-ci-release/artifacts/sbt-ci-release/1.11.2?binary-version=_sbt2_3
- 3: https://github.com/sbt/sbt-ci-release/releases
- 4: https://github.com/sbt/sbt-ci-release/blob/main/readme.md
- 5: https://github.com/sbt/sbt-ci-release/
- 6: https://github.com/sbt/sbt-ci-release/releases/tag/v1.11.0
🌐 Web query:
sbt 2.x inThisBuild API removed breaking change
💡 Result:
In sbt 2.x, the use of ThisBuild scoping for global settings has been fundamentally changed to support a new "common settings" model [1][2]. While the inThisBuild API itself has not been simply "removed" as a breaking syntax in the same way deprecated methods are, the architectural approach to build configuration has shifted, rendering the manual use of ThisBuild for basic settings unnecessary and discouraged [1][2]. Key details regarding this change: 1. Common Settings Model: In sbt 2.x, bare settings defined in build.sbt are automatically interpreted as "common settings" and injected into all subprojects [1]. This replaces the previous role of ThisBuild, which was commonly used in sbt 1.x to apply settings globally [1][2]. 2. Migration Impact: Because these common settings are now injected between plugin settings and those defined in settings(...), they provide more predictable delegation [2]. You no longer need to use the ThisBuild / key:= value syntax for settings like scalaVersion [1]. 3. Delegation and Scoping: This change simplifies build definitions by eliminating the need to explicitly scope settings to ThisBuild to ensure they are shared across subprojects [1][3]. 4. Related Removals: Note that sbt 2.x does include other breaking changes related to older sbt syntax, such as the removal of legacy sbt 0.13 style build.sbt "in" methods (e.g., scalacOptions in (Compile, console)), which should be migrated to the unified slash (/) syntax [4]. For users upgrading, the official recommendation is to adopt the new common settings model by removing explicit ThisBuild scopes for standard project-level settings [2]. This makes builds more predictable and reduces the complexity associated with manual scoping [2].
Citations:
- 1: https://www.scala-sbt.org/2.x/docs/en/changes/sbt-2.0-change-summary.html
- 2: https://www.scala-sbt.org/2.x/docs/en/changes/migrating-from-sbt-1.x.html
- 3: https://eed3si9n.com/sbt-2.0-ideas
- 4: [2.x] Remove sbt 0.13 build.sbt
inmethods sbt/sbt#7702
🌐 Web query:
sbt-mergify-github-actions 0.9.0 sbt 2.0 compatibility
💡 Result:
As of June 16, 2026, version 0.9.0 of sbt-mergify-github-actions does not explicitly claim compatibility with sbt 2.0 [1][2]. Released on September 26, 2024, version 0.9.0 predates the broader adoption of sbt 2.0 [1]. While sbt-mergify-github-actions depends on the sbt-github-actions plugin, which has seen updates to support sbt 2.0 [3], there is no indication that sbt-mergify-github-actions has been updated or released to specifically accommodate the changes introduced in sbt 2.0 [1][2]. If you are migrating to sbt 2.0, you may encounter compatibility issues or require a newer release of the plugin, should one become available, to support the new sbt 2.0 architecture.
Citations:
- 1: https://github.com/nafg/mergify-yaml/releases/tag/v0.9.0
- 2: https://github.com/nafg/mergify-yaml
- 3: sbt/sbt-github-actions@ae62738
🌐 Web query:
sbt 2.0 exportJars default true breaking change getResource
💡 Result:
In sbt 2.0, the exportJars setting now defaults to true, whereas it defaulted to false in previous versions [1][2]. This change means that sbt now uses the packaged JAR file on the classpath instead of the directory containing raw class files and resources [3][4]. This shift can cause issues with code that relies on accessing resources directly from the filesystem (e.g., via getResource("/") or resource.toURI), as these methods may fail with NullPointerException or FileSystemNotFoundException when the resources are inside a JAR file rather than a directory [1][2]. If your build logic is negatively impacted by this change, you can restore the previous behavior by explicitly setting the following in your build definition: exportJars:= false This setting is recommended as a workaround if you encounter compatibility issues, such as those reported with certain plugins or test utilities that assume a directory-based classpath structure [1][2][5].
Citations:
- 1: https://www.scala-sbt.org/2.x/docs/en/changes/migrating-from-sbt-1.x.html
- 2: https://sparkingscala.com/latest/2026/04/11/sbt-2-spark-scala-projects/
- 3: https://www.scala-sbt.org/release/docs/Howto-Classpaths.html
- 4: https://www.scala-sbt.org/1.x/docs/Howto-Package.html
- 5: shading assumes exportJars := false sbt/sbt-assembly#537
🏁 Script executed:
# Check if project uses getResource or exportJars explicitly
rg -i 'getresource|exportjars' --type scala --type sbtRepository: nafg/slick-migration-api
Length of output: 96
Resolve sbt plugin incompatibility before upgrading to sbt 2.0.0.
sbt-coveralls 1.3.15 is not compatible with sbt 2.0.0 (remains sbt 1.x only with no sbt 2.0 release). Additionally, sbt-mergify-github-actions 0.9.0 lacks explicit sbt 2.0 support. Both plugins will fail under sbt 2.0.0.
sbt-scoverage 2.4.4 and sbt-ci-release 1.11.2 are compatible with sbt 2.x.
Update or replace the incompatible plugins with sbt 2.0-compatible versions before merging this change. Alternatively, revert to sbt 1.12.12 and wait for downstream plugin releases.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@project/build.properties` at line 1, The sbt version upgrade to 2.0.0 in
build.properties is incompatible with two plugins in the project's build
configuration: sbt-coveralls 1.3.15 is sbt 1.x-only with no sbt 2.0 release, and
sbt-mergify-github-actions 0.9.0 lacks explicit sbt 2.0 support. Before merging
this change, locate and update these plugin versions in the build configuration
(likely in project/plugins.sbt or similar) to sbt 2.0-compatible versions, or
replace them with compatible alternatives. The sbt-scoverage 2.4.4 and
sbt-ci-release 1.11.2 plugins are already compatible and require no changes. If
compatible versions are unavailable, revert the sbt version back to 1.12.12.
|
Tick the box to add this pull request to the merge queue (same as
|
1 participant
About this PR
📦 Updates org.scala-sbt:sbt from
1.12.12to2.0.0⚠📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a
.scala-steward.conffile.Have a fantastic day writing Scala!
⚙ Adjust future updates
Add this to your
.scala-steward.conffile to ignore future updates of this dependency:Or, add this to slow down future updates of this dependency: