support Scala.js

[SethTisue]

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

[SethTisue]

@cunei when you fixed #188, did you take the path @dwijnand suggested, or a different one?

[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.

[cunei]

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.

[dwijnand]

I expressed myself inprecisely.

To recap, the default behaviour when using Scala.js' cross-build support will:

• Create two sbt projects, with distinct ids, eg. fooJVM and fooJS
• But give them the same name, eg. foo
• Then be default moduleName is defined in terms of name (via normalizedName), so still foo

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.

[cunei]

@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.

[sjrd]

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

[dwijnand]

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

[SethTisue]

some more recent discussion at https://github.com/scala/community-builds/issues/798 and https://github.com/scala/community-builds/issues/799

[SethTisue]

highly unlikely to ever happen