TASTy Compatibility After a Scala 2.13→3 Upgrade: Clean Rollback
0 reputation · 10 Sept 2022, 05:40 UTC
0 reputation · 10 Sept 2022, 05:40 UTC
Restore a project to a working Scala 2.13 state after a partially applied upgrade to Scala 3, without leaving mixed‑version artifacts that could corrupt future builds.
Scala 3 compiles to TASTy files that embed a format version. The 2.13 compiler cannot consume TASTy produced by a newer compiler, so any leftover Scala 3 TASTy in the classpath will break the rollback. SBT’s incremental cache and locally published modules may still reference these TASTy files, even after the scalaVersion has been reverted and the _3 dependency suffixes removed.
There is no built‑in SBT or compiler mechanism that automatically detects or cleans up stray Scala 3 TASTy artifacts when rolling back. It is unclear whether a simple sbt clean is sufficient or if additional steps are required.
sbt clean remove all cached TASTy files generated by the Scala 3 compiler, or must a manual cache purge be performed?_3 to _2.13) across all modules in a multi‑project SBT build?33775 reputation · 10 Sept 2022, 16:36 UTC
sbt clean does not remove Scala 3 TASTy files that may be cached in your local Ivy2 or Coursier repositories; those artifacts must be purged manually before a clean rollback to Scala 2.13 will succeed.
Explanation: Scala 3 compiles to TASTy with a format version that the Scala 2.13 compiler cannot read. If any TASTy‑containing JAR remains on the classpath (e.g., in the local cache), the 2.13 compiler will fail with a "TASTy version" error, even after you have reverted scalaVersion and removed the _3 suffix from dependencies.
Confirmed facts from the research:
sbt clean deletes only the target/ directories of your project; it does not touch ~/.ivy2/local or ~/.coursier where locally published JARs (and their embedded TASTy) reside.*.tasty under those cache directories, or by inspecting JARs with unzip -l and grepping for .tasty. The file magic number starts with 0x00 0x01 0x0A (UTF‑8 "TASTy")._3 → _2.13), set scalaVersion := "2.13.x" and rely on SBT’s cross‑version operators (%% or %%%). A full reload (sbt reload) or an update (sbt update) will then resolve all dependencies with the correct suffix.Revert the Scala version in build.sbt (or wherever it is defined):
scalaVersion := "2.13.12" // or your preferred 2.13.x
Remove any explicit _3 suffixes from libraryDependencies (if you added them manually); otherwise keep the cross‑version operators (%%) so SBT will automatically apply the _2.13 suffix.
Run a clean to delete compiled class files:
sbt clean
Purge locally cached Scala 3 artifacts:
rm -rf ~/.ivy2/local/<your‑organization> (or search and delete only the relevant modules).rm -rf ~/.coursier/cache/v1/https/repo1.maven.org/maven2/<your‑organization> (or use coursier purge if available).Alternatively, run a search to verify no TASTy remains before proceeding:
find ~/.ivy2/local ~/.coursier -type f -name "*.tasty" -print
# or, to inspect JARs:
find ~/.ivy2/local ~/.coursier -type f -name "*.jar" -exec sh -c 'unzip -l {} | grep -q \.tasty' \; -print
Reload the build and update dependencies so that SBT resolves them with the _2.13 suffix:
sbt reload
sbt update
Compile to confirm the rollback succeeded:
sbt compileIf the console shows no "TASTy version" warnings, the classpath is free of Scala 3 TASTy files.
(Optional) Verify dependency resolution:
sbt "show libraryDependencies"
All entries should display the _2.13 suffix (or no suffix for purely cross‑built artifacts).
If you are unable to locate the exact cache directories used by your organization (e.g., you publish to a custom local Ivy2 repository), please provide the base path of that repository so the purge command can be adjusted accordingly.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.