You most certainly can: use an environment variable as detailed in the release notes of Scala.js 1.0.0-M1. It might not be ideal, as opposed to
++, but it’s definitely possible and has very little boilerplate. Also, things like Travis have very good support for running a matrix with different environment variables.
Again, I acknowledge that it is not ideal compared to
++, but I cannot take “You cannot right now do this” as valid criticism. I’m willing to discuss how we can improve this, but I first need someone starting to give at least a starting idea on how this could be done better, taking into account the technical constraints. For example, just saying “there should be a command
**1.0.0-M1 in sbt to switch to Scala.js 1.0.0-M1” does not take technical constraints into account, because you need a different sbt plugin to be on the classpath of your build to be able to switch the version of Scala.js, and a command does not have the power to change the classpath of the build. I also have several times heard people suggesting that sbt-scalajs should be a tiny shell independent of the actual version of Scala.js, and load the linker and everything else reflectively in a
ClassLoader. This is viable, though quite complex, until you start considering other sbt plugins depending on sbt-scalajs, such as
I will say it again: I don’t have any idea to solve this, but if someone does, I am all ears.
OK, that’s the first time I hear about this one. Let’s add it to the list. I’m not sure why it happens. I mean it would obviously take “twice the time” to resolve the setting dependency of a
crossProject (which really is 2
projects) vs one
project, but from your comment it sounds like this is more than 2x?
Is that really related to Scala.js cross-compilation or to sbt multi-projects in general? I used to recommend to people that they always use a
commonSettings, except for the very specific case of
crossScalaVersions. That was easy to understand and apply (even though maybe not understand why), but apparently it confuses some tools like Ensime. Now my recommendation would be: try
in ThisBuild first for any common settings that you have, and if that has no effect for a particular setting, put it in
commonSettings. An easy way to test whether it has any effect is not to put in the build, start up sbt, then
set it dynamically.
set will tell you how many other settings and tasks are affected by the change. If it says 0, chances are it does not have any effect.
I did not comment on this earlier because it seemed to me that the DateTime questions were kind of rhetorical. Of course we can write a standard Scala date-time API. Why don’t we? Probably because it’s too big an endeavor to undertake given that
java.time already exists and is “good enough”. So yes, we should definitely port
java.time to all the platforms, and there are various efforts in this direction. The fact that there are 3 competing solutions is a real bummer. We first made
scalajs-java-time, but then other people created competing solutions instead of contributing to the existing one. At that point I don’t know what to do anymore. Am I supposed to take an authoritarian position and declare one of the alternatives the right one, and encourage everyone to shun the other ones? What if the other ones do have some parts of the API that are not supported in the right one yet?
I’m genuinely asking those questions. The
java.time situation bothers me.
To this particular point:
I don’t understand because, as mentioned above, the JDK 8
java.time API is ported (3 times).
So, you’re saying that since
sbt-doge solved that issue before, which was “similar”, why is it that we haven’t solved platform cross-compilation yet? I can answer that. I very much wish myself that we had solved that already.
The fact is that
sbt-doge had a much easier problem to solve. For starters, it was already definitely possible to publish some modules with 2.10 and 2.11 support, while other modules supported 2.12 too. You just could not use
+, and instead had to use
++ has always worked, way before sbt-doge came. I know because I have used it since the beginning of Scala.js supporting several Scala versions, and I am still doing so across 18 minor versions of Scala for about 20 modules in Scala.js, that support different subsets of Scala versions.
All that sbt-doge solved was to take into account
crossScalaVersions at the project level rather than at the build level, which means that it made
+ work in addition to
++ in such situations. It certainly was a worthwhile improvement, but not a fundamental one.
For the Scala.js cross-compilation issue, even though it can appear as “similar” on a very cursory glance, it is very different.
++ itself doesn’t work, never mind
+. And I have commented above about why we could not make
++ work for Scala.js cross-compilation (or at least haven’t managed to do so).
If someone comes up with a solution that makes some kind of
++ command work for Scala.js, I will jump on the solution and distribute it right away. I haven’t been able to come up with a solution for that myself, though. I hope someone finds something where I failed.
It is not ideal for downstream users of libraries, but it is ideal for the Scala/JVM library maintainer. You have to give that solution that much credit.
Package and artifact names can be the same, only the
groupID has to change. This could potentially be addressed if the JVM maintainer allows a trusted JS maintainer to publish the Scala.js artifacts in the same groupID.