sbt-scalafmt `2.6.0` "corrupted class path" when consumed transitively through another sbt plugin

[Rossbro2]

Problem

sbt-scalafmt 2.6.0 fails with corrupted class path when it is consumed transitively through another sbt plugin, rather than declared directly in a project's plugins.sbt.

This works fine:

// project/plugins.sbt
addSbtPlugin("org.scalameta" %% "sbt-scalafmt" % "2.6.0")

This fails:

// my-sbt-plugin publishes with sbt-scalafmt 2.6.0 as a dependency
// downstream project's plugins.sbt
addSbtPlugin("com.example" %% "my-sbt-plugin" % "1.0.0")
// sbt-scalafmt 2.6.0 is resolved transitively

Error

[error] (Compile / scalafmtCheck) org.scalafmt.sbt.ScalafmtSbtReporter$ScalafmtSbtError:
  scalafmt: [v3.11.0] corrupted class path:
  [/path/to/.cache/coursier/v1/https/.../scalafmt-core_2.13-3.11.0.jar ...]

Root Cause

The 2.6.0 release (changelog) changed from scalafmt-dynamic's own isolated jar downloader to sbt's native dependency resolution ("Implement scalafmt-dynamic downloader using sbt").

When sbt-scalafmt is bundled inside another sbt plugin and consumed transitively:

1. scalafmt-core 3.11.0 classes end up on the parent sbt classloader (via the host plugin's transitive dependencies)
2. scalafmt-dynamic also loads scalafmt-core into its own isolated classloader
3. The classloader validation in scalafmt-dynamic sees the same classes on both classloaders and fails with "corrupted class path"

When declared directly in plugins.sbt, the classes only appear on one classloader, so validation passes. This is why the issue only manifests in the transitive case.

Steps to Reproduce

1. Create an sbt plugin that depends on sbt-scalafmt 2.6.0:

   // my-plugin/build.sbt
   sbtPlugin := true
   addSbtPlugin("org.scalameta" %% "sbt-scalafmt" % "2.6.0")

2. Publish that plugin locally
3. In a downstream project, consume the plugin transitively:

   // downstream/project/plugins.sbt
   addSbtPlugin("com.example" %% "my-plugin" % "1.0.0")

4. Add a .scalafmt.conf with version = "3.11.0"
5. Run sbt scalafmtCheck → fails with "corrupted class path"

Environment

• sbt 1.12.10
• Scala 2.13
• Java: Amazon Corretto 25
• useCoursier := false (Ivy resolution), though likely also affects Coursier
• sbt-scalafmt 2.6.0 with scalafmt 3.11.0

Workaround

Revert to sbt-scalafmt 2.5.6, which uses the old isolated downloader approach and does not conflict with transitive classloading.

[Rossbro2]

@kitbellew can you take a look?

[kitbellew]

i am not an expert on this issue, alas. if someone knows how to separate these classloaders, would be happy to follow along.

@tgodzik @eed3si9n any pointers?

[tgodzik]

Not something I have time for currently, since classloaders always seem a rabbit hole. What is the use case here? Is it a problem when just using scalafmt as a plugin or does you plugin require scalafmt-sbt to function?

[Rossbro2]

@tgodzik To answer your question — our sbt plugin (sbt-core) is an organization-wide auto-plugin that bundles common settings, dependencies, and plugins for ~50+ downstream projects. It declares
sbt-scalafmt as a dependency so formatting is configured consistently without each project adding it manually.

 // sbt-core (our auto-plugin) build.sbt
 sbtPlugin := true
 addSbtPlugin("org.scalameta" %% "sbt-scalafmt" % "2.6.0")

 // downstream project plugins.sbt
 addSbtPlugin("com.example" %% "sbt-core" % "15.1.36")
 // sbt-scalafmt 2.6.0 resolved transitively — "corrupted class path"

The downstream projects don't declare sbt-scalafmt themselves — it comes purely through the transitive dependency. This worked fine with ≤2.5.6 (scalafmt-dynamic's isolated jar downloader) but breaks with
2.6.0's switch to sbt's native dependency resolution.

We're pinning to <2.6.0 as a workaround, but it'd be great if transitive consumption could be supported again.

[Rossbro2]

@kitbellew / @tgodzik - suggested fix in #441