This is NOT the release announcement of Scala.js 1.0.0

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). :frowning:

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

scala-parser-combinators 1.1.2 is now published for Scala.js 1.0

1 Like

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…

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

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

  3. this isn’t just a one-time task; it’s a repeated process every time you do a release

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

it’d make sense perhaps to replace this announcement by the 1.0.0 release? It’s much more likely to be relevant going forward.

Congratulations by the way!

The real announcement has been made here: Announcing Scala.js 1.0.0

Not really sure what you mean by “replace”.

at least in other tools, announcements tend to be sticky. but perhaps that’s not the case here. either way, the link you’ve shared should be the last reference for anyone arriving to this thread by mistake.

I’ve just back-published shapeless 2.3.3 for Scala.js 1.0.0 and Scala 2.11, 2.12 and 2.13.

5 Likes

From version 0.6.4 onwards, Slinky is cross-published for Scala.js 0.6/1.0 and Scala 2.12/2.13! 0.6.4+2-3c8aef65 is the recommended version for those using Scala.js 1.0 since a couple bugs were found by the community in the initial release.

3 Likes

@shadaj, my class will be using Slinky in April. The setup I gave them is for Scala.js 0.6.31 and Slinky 0.6.3. I’m trying to decide if I should have my students move to Scala.js 1.0 knowing that for many the editing of the .sbt files will cause some challenges. Do you have any thoughts or recommendations?

I sympathize with the technical difficulty of cross-building against Scala.js 0.6.x and 1.x. The solution based on environment variables is the best we could ever come up with. Unfortunately, that model is at severe odds with the model of sbt-release, and there is not much we can do about that.

I don’t see any solution at reconciling sbt-release with sbt-scalajs cross-versioning. It seems the only real solutions are to ditch one or the other.

Note that I never recommended sbt-scalajs, but it is the right technical foundation for cross-building Scala.js without having to reload sbt with different env vars. When the first milestones of Scala.js 1.x were released, some people basically demanded that I build it. I did; no one ever used it (according to Scaladex), which I take as evidence that whatever the pain of using an env var is, it is less than the limitations imposed by sbt-dynscalajs.

Note that I don’t want to advocate for or against keeping support for 0.6.x or not. I believe it is each maintainer’s choice to do so. I am only trying to give as much help and guidance as possible to those who want to cross-compile.

1 Like