Starting with Scala 3.8.0, Scala 3.x is taking ownership of scala-library.jar. That means there will be a scala-library % 3.8.0, which will supplant scala-library % 2.13.16 in dependency resolution.

On the JVM, the artifact migration strategy is planned as follows:

• scala3-library (which previously contained Scala 3-specific additions of the std lib) will be an empty artifact, with a dependency on scala-library
• scala-library v3.x will contain all of the classes of what was previously scala-library and scala3-library.

This ensures that, through dep resolution, users will always get what they need.

The build of Scala 3, today, also publishes an sjs version of scala3-library. It publishes scala3-library_sjs1 % 3.7.0. This artifact depends on scalajs-scalalib % 2.13.16+1.19.0, which is consistent with the fact that its JVM counterpart depends on scala-library % 2.13.16.

The big question is thus: what happens to scalajs-scalalib and scala3-library_sjs1 in the new world where Scala 3 owns the std lib?

After some discussion with @hamzaremmal, we suggest the following strategy:

• Make scala3-library_sjs1 an empty shell that depends on scalajs-scalalib (consistent with its JVM counterpart)
• Publish scalajs-scalalib % 3.8.0 (not 3.8.0+1.19.0)

Both would be built and published by the Scala 3 build. The Scala.js build would not change. It would keep publishing Scala 2 artifacts only.

So what exactly do they contain? This is trickier than it looks, since today, the treatment of class files is not uniform across those artifacts. Today, we have:

• scala-library.jar contains class files for scala:src/library/
• scalajs-scalalib.jar contains the corresponding sjsir files (and it depends on scala-library.jar)
• scala3-library_sjs1.jar contains both class and sjsir files for scala3:library/src/ and scala3:library-js/src/ (and tasty as well). The latter contains two extra classes: UnitOps and (deprecated) AnonFunctionXXL. It depends on scala-library.jar and scalajs-scalalib.jar.

In the new world of Scala 3, the compiled form of both scala:src/library and scala3:library/src/ are in scala-library.jar. The reason for the sjsir/class file split in Scala 3 was that Scala build tools really don't like not having scala-library.jar on the classpath. So it was never realistic to put the class files in our own scalajs-library. It is very likely that the build tools will still panic if they don't see scala-library in the new Scala 3 world. That means they will necessarily get the tasty and class files of scala:src/library/ and scala3:library/src/. However, it won't contain tasty and class files for UnitOps and AnonFunctionXXL.

Translating our current requirements into the new world would mean the following:

• scala-library.jar contains tasty and class files for scala:src/library/ and scala3:library/src/
• scalajs-scalalib.jar contains the sjsir for the above, plus tasty, class and sjsir of UnitOps and AnonFunctionXXL.

Regarding scalajs-library.jar, it will stay exactly as is. It will only be built for Scala 2, by the Scala.js repo. Hence it will contain class and sjsir files, but no tasty.

scalajs-scalalib % 3.8.0 will trump 2.13.16+1.19.0 in dep resolution. There is no +1.19.0 suffix because the Scala 3 build always has exactly one Scala.js version.

If we follow that plan, concretely, here is what we need to do:

• In the scala-js repo, nothing changes (not even in the sbt plugin).
• In the scala3 repo, we need to add a project to build the sources of scala:src/library/ (with Scala.js-specific overrides, unfortunately maintained as a copy in the Scala 3 repo).
• The Scala 3 repo will need to publish "org.scala-js" % "scalajs-scalalib" % "3.x".

The last bullet has implications on Sonatype access rights. Today, projects on the GitHub scala-js organization publish to org.scala-js, while the GitHub scala organization publishes to org.scala-lang. With these changes, the scala organization will publish to org.scala-js as well.

@gzm0 WDYT? Does this seem reasonable?