Fix #1103: Scala 3 support for Scala.js #1187
Conversation
lolgab
force-pushed
the
scala-js-scala3
branch
from
ebf2ffa
to
463ecb9
Compare
| @@ -107,7 +107,7 @@ object Lib{ | |||
| else if (mill.scalalib.api.Util.isScala3(scalaVersion)) | |||
| Agg( | |||
| // note that dotty-library has a binary version suffix, hence the :: is necessary here | |||
| ivy"$scalaOrganization::scala3-library:$scalaVersion".forceVersion() | |||
| ivy"$scalaOrganization::scala3-library::$scalaVersion".forceVersion() | |||
There was a problem hiding this comment.
I want it to be scala3-library_sjs1_3.0.0-RC1 on Scala.js
There was a problem hiding this comment.
Yeah, that was obvious. Sorry for the poor question. I was wondering, why that works at all, as this method is also used outside of a Scala.js context. I would expect it to fail when compiling a simple scala project. Also this should affect Scala Native modules. My initial though was, that a Scala.js specific runtime/ compiler classpath should be applied to the ScalaJsModule, not the ScalaModule. You see me confused.
There was a problem hiding this comment.
platformSuffix works on any platform. It works correctly on ScalaModule because platformSuffix = "".
The main difference between Scala 2 and Scala 3 on Scala JS is that the Scala.js backend is not implemented as a compiler plugin but inside the Scala 3 compiler. So if Scala 2 removes the scala-library and replaces it with its scalajs-library (as you can see there is no super.scalacPluginIvyDeps() ++ in the Scala2 part of scalacPluginIvyDeps, which means that we don't want the scala-library from Scala but we'll use the Scala.js one instead), the Scala 3 compiler emits different scala3-library artifacts for every backend.
Regarding Scala Native, I expect that when it will be supported, its support will be done in a similar fashion as the Scala.js one, so there will be a scala3-library_native0.x_3... artifact that the ScalaNativeModule will automatically use.
I apologise in advance with the Scala.js team if I said something not completely precise.
There was a problem hiding this comment.
Thank you for that explanation. And sorry for not knowing that specific part of the Mill API better. The platform suffix handling still feels a bit odd, but that is another discussion. PR looks good to me!
There was a problem hiding this comment.
Nothing to be sorry of! Thank you for the review and the merge 🙏😃
There was a problem hiding this comment.
Ok, I wasn't that wrong with my suspicion. This assumes we only build with plain Scala Module or one of the built-in platform versions ScalaJSModule or ScalaNativeModule. But the platform concept is more general and if one module sets it to be unequal ""`, this implementation will fail. Instead, we should revert that specific line and implement it more specifically in the both modules that need it.
E.g. imagine, someone tries to build a Mill plugin with Scala 3 (which is currently not supported), the you would run into the following issue:
object millroot extends MillBuildRootModule {
override def scalaVersion = "3.3.0"
// ..
}>> mill --meta-level 1 ivyDepsTree
[build.sc] [30/52] resolvedIvyDeps | Downloading [2/2] artifacts (~0/0 bytes)
1 targets failed
resolvedIvyDeps
Resolution failed for 1 modules:
--------------------------------------------
org.scala-lang:scala3-library_mill0.11_3:3.3.0
not found: /Users/me/ivy2/local/org.scala-lang/scala3-library_mill0.11_3/3.3.0/ivys/ivy.xml
not found: https://repo1.maven.org/maven2/org/scala-lang/scala3-library_mill0.11_3/3.3.0/scala3-library_mill0.11_3-3.3.0.pom
Example adapted from https://matrix.to/#/!zXvttAKLPnvdnmiYsY:matrix.am/$FU_LdtZ6RFNOtmpbIlCGGzlkzWAV0NPUaF2BE7F2sqI?via=matrix.am&via=gitter.im&via=matrix.org
|
Thank you! |
No description provided.