support Scala.js
SethTisue opened this issue · comments
I don't know what the chances of this happening are, but let's have a ticket for it, at least.
currently in the Scala community build we have to disable Scala.js subprojects since it's pretty much guaranteed that dbuild will complain that the JVM subproject and the corresponding Scala.js subproject publish the same artifact.
over at #188, @dwijnand suggested that (in order to fix a different issue) dbuild ought to determine uniqueness using the artifactId
:
This would allow, as an example, dbuild to not fail when seeing both a cats-core for JVM and a cats-core for JS, by seeing them as org.typelevel#cats-core_2.11 and org.typelevel#cats-core_sjs0.6_2.11 instead
/cc @sjrd
Edit: Oops sorry I didn't read the initial description well enough. My comment below appears to repeat @dwijnand's suggestion.
dbuild will complain that the JVM subproject and the corresponding Scala.js subproject publish the same artifact
They do not, though. For a cross-compiled foo
project, the JVM subproject publishes foo_2.11
whereas the JS subproject publishes foo_sjs0.6_2.11
. If dbuild complains that those are the same, I guess the first thing to look at would to fix that.
According to @dwijnand, the issue is a bit different from the one in #188. In ScalaJS, it seems, the name
setting only contains the plain name, while the ScalaJS-specific suffix gets added only during publishing. Except dbuild resets the publish
task to the default value, in order to capture the produced artifacts; in addition, it only checks the name
setting in order to, well, find the name. So I have to look into adding explicit support for ScalaJS artifacts, and the related special name mangling.
I expressed myself inprecisely.
To recap, the default behaviour when using Scala.js' cross-build support will:
- Create two sbt projects, with distinct
id
s, eg.fooJVM
andfooJS
- But give them the same
name
, eg.foo
- Then be default
moduleName
is defined in terms ofname
(vianormalizedName
), so stillfoo
See:
- https://github.com/scala-js/scala-js/blob/v0.6.13/sbt-plugin/src/main/scala/org/scalajs/sbtplugin/cross/CrossProject.scala#L295-L298 and
- https://github.com/sbt/sbt/blob/v0.13.13/main/src/main/scala/sbt/Defaults.scala#L1200
At some point the end artifactId
(as found in the POM's and artefact file names) we do name mangling. Giving us artifactId's such as foo_2.11
and foo_sjs0.6_2.11
. I'm not sure exactly where, I tried looking last time and couldn't find it. I meant when "publishing" - I'm not sure it's exactly in the publish
task.
@dwijnand Thanks for the clarification! Yes, I use moduleName
in dbuild to determine the artifact name, see https://github.com/typesafehub/dbuild/blob/d464e487e4373270315429d850ff253e040947fc/plugin/src/main/scala/com/typesafe/dbuild/plugin/DBuildRunner.scala#L801
I'll track down where exactly the further renaming takes place; I need to mimic that by using the same logic that ScalaJS uses in order to generate the proper artifact information in dbuild.
Scala.js does not override publish
, so resetting publish
should not be an issue. The way it adds its suffix is through the crossVersion
sbt setting, here: https://github.com/scala-js/scala-js/blob/v0.6.13/sbt-plugin/src/main/scala/org/scalajs/sbtplugin/ScalaJSPluginInternal.scala#L991
That's it. dbuild
- throws away the value inside CrossVersion.Binary: https://github.com/typesafehub/dbuild/blob/d464e487e4373270315429d850ff253e040947fc/plugin/src/main/scala/com/typesafe/dbuild/plugin/DBuildRunner.scala#L786
- that you had set: https://github.com/scala-js/scala-js/blob/v0.6.13/sbt-plugin/src/main/scala/org/scalajs/sbtplugin/ScalaJSCrossVersion.scala#L40
some more recent discussion at scala/community-build#798 and scala/community-build#799
highly unlikely to ever happen