We are pleased to announce the release of Scala.js 1.1.0!
The highlight of this release is the new support for @js.nativeval s and def s. The version of the Scala standard library has been upgraded to Scala 2.12.11 and 2.13.2. In addition, it contains a number of bug fixes, including all the ones fixed in v0.6.33.
Important note: if you use scalajs-bundler, you will need to upgrade it to v0.18.0 or later.
Read the announcement on the Web for more details:
Should cross-built libraries keep both 1.0 and 1.1 in their cross-builds? Or keep just 1.0, for maximum compatibility? Or keep just 1.1, in the interest of nudging the whole ecosystem onto the new version?
What happens if a 1.0 user tries to use a library that was published from 1.1? (Is the artifact _sjs1_ regardless?)
It is backward binary compatible with all earlier versions in the 1.x series: libraries compiled with 1.0.x can be used with 1.1.0 without change.
It is not forward binary compatible with 1.0.x: libraries compiled with 1.1.0 cannot be used with 1.0.x.
It is not entirely backward source compatible: it is not guaranteed that a codebase will compile as is when upgrading from 1.0.x (in particular in the presence of -Xfatal-warnings ).
So no, definitely do not cross build for 1.0 and 1.1. You’d be publishing an artifact twice. (It’s like trying to cross build for Scala 2.13.1 and 2.13.2: that doesn’t make sense.) As for which one to use in your build, use whatever makes you happy, but I guess most people would choose to upgrade.
If they’re using sbt, they’ll get a nice error message when linking telling them to upgrade their sbt-scalajs to 1.1.x. Other build tools may report a less nice error message, but in any case it will be clear that they’re trying to use a 1.1.x library from 1.0.x.
I’m thinking particularly of very low-level dependencies like the Scala modules and ScalaCheck. If they move to 1.1, that will force a lot of upgrades downstream. But it sounds like you’re fine with that. Which is what I wanted to know
