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.
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ā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.
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.
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)
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.
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.