The missing release is there now (https://repo1.maven.org/maven2/org/scala-lang/modules/scala-collection-compat_2.12/2.1.4/)
5 Likes
Airframe and AirSpec testing framework are now available for Scala.js 1.0.0 https://wvlet.org/airframe/
3 Likes
Kudos to Rickard Nilsson for granting merge and publishing authority to a set of maintainers that now includes Aaron Hawley, Daniel Spiewak, and Erik Osheim. (And myself, though mostly as a backup in case we run short.)
Seth
4 Likes
uPickle/uJson/uPack is out for Scala.js 1.0.0:
com.lihaoyi::upickle::0.9.9
Currently missing Scala.js 1.0.0 versions of the following libraries for my own internal projects:
3 Likes
Scala Verify is back published for Scala 2.11 ~ 2.13 (thanks @SethTisue for porting):
libraryDependencies += "com.eed3si9n.verify" %%% "verify" % "0.2.0" % Test
testFrameworks += new TestFramework("verify.runner.Framework")
Expecty is also back published for 2.11 ~ 2.13:
libraryDependencies += "com.eed3si9n.expecty" %%% "expecty" % "0.13.0" % TestThe following Typelevel libraries are available for Scala.js 1.0.0:
"org.typelevel" %%% "alleycats-core" % "2.1.0""org.typelevel" %%% "alleycats-laws" % "2.1.0""org.typelevel" %%% "cats-core" % "2.1.0""org.typelevel" %%% "cats-free" % "2.1.0""org.typelevel" %%% "cats-kernel" % "2.1.0""org.typelevel" %%% "cats-kernel-laws" % "2.1.0""org.typelevel" %%% "cats-laws" % "2.1.0""org.typelevel" %%% "cats-macros" % "2.1.0""org.typelevel" %%% "cats-testkit" % "2.1.0""org.typelevel" %%% "claimaint" % "0.1.3""org.typelevel" %%% "claimaint-mc" % "0.1.3""org.typelevel" %%% "discipline-core" % "1.0.2""org.typelevel" %%% "discipline-scalatest" % "1.0.1""org.typelevel" %%% "simulacrum" % "1.0.0"
I’m not planning to publish any Circe modules for 1.0.0 until all of the dependencies in the main repo are available, which means Circe is blocked by Shapeless, Refined (which is also blocked by Shapeless), scala-java-time, scodec-bits, and maybe Scoverage (IIRC I can’t publish without Scoverage support for the current Scala.js version for some reason). I don’t think cats-effect has any blockers beyond the fact that nobody’s done the work to update the build yet.
6 Likes
ScalaTest 3.1.1, released recently, supports Scala.js 1.0.0. (Not thanks to me, but thanks to Bill Venners & Chee Seng.)
1 Like
We’ve now published a follow-up 2.1.1 Cats release that seems to be working on Scala.js 1.0.0.
2 Likes
It means cats 2.2 release will not be supported by scalajs 0.6? If it is planned in near future (I’ve heard that) then maybe it should be published also to scalajs 0.6? There are projects that will not migrate to 1.0 so quickly (I expect to be able to migrate ~0.5year or more). 
Not sure which release you mean by “it should be published also to scalajs 0.6”, but Cats 2.1.1 does support both Scala.js 1.0.0 and 0.6 now.
If you mean Cats 2.2.0, the cross-building release process is quite inconvenient and I’m hoping we can drop it in favor of Scala.js 1.0.0 releases, although I guess if there’s enough demand we can continue both.
I’ve also just published most of Circe’s core modules for Scala.js 1.0—please see the final section of the 0.13.0 release notes for details: https://github.com/circe/circe/releases/tag/v0.13.0
2 Likes
I’m with Travis on this. Cross-publishing for multiple Scala versions is ok because there is SBT support for it, but cross-publishing for multiple Scala.JS versions is a pretty significant headache. There isn’t SBT support for it and it requires env-hacks and starting SBT multiple times. This might not sound like a big deal but it means that…
-
you end up with two separate release processes. One where you get sbt to sign, publish, and tag everything (assuming you’re using sbt-release). Then another where you go back and redo just the signing and publishing part of the release for an alternate Scala.JS version.
-
wrt modules cross-building for Scala and Scala.JS, when you do your second ad-hoc release, you have to ensure that you only publish the Scala.JS modules and not the Scala ones (seeing as they were already released). If you have lots of modules (as I tend to in order to integrate with many community libraries without making them mandatory dependencies), this is a lot of error-prone manual work.
-
this isn’t just a one-time task; it’s a repeated process every time you do a release
-
when you have lots of OSS libraries, you multiple the above. I have 10 and every one is published for Scala.JS. That’s a huge amount of work!
Ideally I’d like to just make the switch from 0.6 to 1.0 and not bother about cross-building. I’d actually encourage the community to do the same, else this nightmare will continue for longer, and affect more libraries maintainers (the vast majority of whom aren’t paid for all this tedious maintenance). I love Scala so much, but no other language ecosystem has demanded even 5% of the library maintenance cost that Scala does. It’s no joke. I’m really, really hoping that TASTY will address the majority of this but until then, I feel that multiple Scala.JS version support is just the cement mixer that breaks the camels back.
Hmmm, I hope that’s not too ranty.
In other news, an update on my OSS libs is that only one (UnivEq) is currently publishable, and all the rest are blocked by Monocle which is blocked by Shapeless, scodec-bits, etc.
5 Likes
I back published scopt 3.7.1 and 4.0.0-RC2 for Scala 2.11 ~ 2.13 on Scala.JS 1:
libraryDependencies += "com.github.scopt" %%% "scopt" % "3.7.1"
3 Likes
I agree we should all just drop Scala.js 0.6 support.
(Either lazily, the first time it causes trouble, or eagerly, to avoid trouble before it starts — whatever the individual maintainer prefers.)
1 Like
For users of sbt-ci-release, there’s a discussion about how to back-publish existing versions for new targets, here: https://github.com/olafurpg/sbt-ci-release/issues/102 . But also, I see a lot of maintainers choosing to simply publish a new version when they add a new target such as Scala.js 1.0, rather than back-publish an existing version.
I don’t disagree with David’s characterization of the difficulty of being a Scala library maintainer, but I think standardizing on sbt-ci-release does help quite a bit. Both because sbt-ci-release itself is good, and also because if we’re all using it, then we can share knowledge with each other and transfer our knowledge between the different repos we contribute to.
1 Like
FWIW cross building Scala.js versions using Mill is trivial (works same as Scala versions). My understanding is that @sjrd’s plugin https://github.com/sjrd/sbt-dynscalajs is meant to make cross building Scala.js versions in SBT equally straightforward. Could that be worth trying?
(I don’t have any stake in whether people publish for sjs0.6 or not, just offering this up in case it makes your lives better)
3 Likes
squants 1.6 was back published for Scala.js 1.0.0
1 Like
Eric published specs2, except the modules that require Shapeless.
2 Likes