Bump back to Scala.js 1.5.1

[armanbilge]

Opening this for consideration in parallel to the discussion in #4016. The scala-js-dom project for example specifically stays on SJS 1.5.x (and only abandoned SJS 1.0.x for Scala 3 support).

[rossabaker]

I don't know the ramifications of a downgrade of Scala.js for something already published. Is it true that whatever is selected here is not transitive to Scala.js apps or downstream libraries?

I'm a deferential 👍 if this doesn't affect downstream and a stronger 👎 if it could.

[armanbilge]

I don't know the ramifications of a downgrade of Scala.js for something already published.

Oh sorry, I should have clarified. The last cats release was on SJS 1.5.1.

https://github.com/typelevel/cats/blob/v2.6.1/project/plugins.sbt#L14

[rossabaker]

Oh, cool. For my education: say cats-2.6.1 were already on 1.7.1. Would this have any affect outside this repo, other than enhancing its reach?

This is a one-line change, with no apparent user-facing disadvantage. But:

• Do we lose any warnings? This is why on the Scala 3.x debate, a Scala 3.latest run is proposed even if not published.
• Do we lose any efficiency of compiled artifacts? I would think no, because that will be up to the app version at linking time?

[armanbilge]

Politely pinging @sjrd for authoritative answers, but my best understanding as follows:

For my education: say cats-2.6.1 were already on 1.7.1. Would this have any affect outside this repo, other than enhancing its reach?

I think we'd have to be mindful of binary compatibility when doing this, just like if we published against Scala 3.1.x and decided to rollback to 3.0.x. But besides that, I don't see why this would be a problem.

Do we lose any warnings? This is why on the Scala 3.x debate, a Scala 3.latest run is proposed even if not published.

We would, although glancing through the release notes I don't see anything notable: https://www.scala-js.org/news/
For example SJS 1.8+ will be including a new warning related to the default execution context, but this doesn't affect cats specifically: scala-js/scala-js#4556

Also it's important to note that running CI against 3.1 requires SJS 1.7.1: scala-js/scala-js-dom#610 (comment). So probably this latest CI run should use the latest Scala with the latest SJS.

Do we lose any efficiency of compiled artifacts? I would think no, because that will be up to the app version at linking time?

I think you are right on this, it's more of a link-time issue.

[sjrd]

Oh, cool. For my education: say cats-2.6.1 were already on 1.7.1. Would this have any affect outside this repo, other than enhancing its reach?

Maybe, maybe not. I can't think of anything specifically between 1.5.0 and 1.7.1. But in general we don't promise anything of the sort. We make no guarantee that reverting to an older release of Scala.js will preserve the binary compatibility of the compiled artifacts. We only make that guarantee in the upgrade direction (changing from 1.5.0 to 1.7.1).

• Do we lose any warnings? This is why on the Scala 3.x debate, a Scala 3.latest run is proposed even if not published.

In general, yes. Specifically between 1.5.0 and 1.7.1, I don't think so. For the upcoming 1.8.0, there would definitely be the new ExecutionContext.global warnings, mentioned by @armanbilge.

• Do we lose any efficiency of compiled artifacts? I would think no, because that will be up to the app version at linking time?

Probably not. The overwhelming majority of efficiency-related stuff is done at link time, or in the library code, both of which are not impacted by the version that you use for your repo, but by the version used in the final application. It can happen that we improve the backend code generator to produce more efficient IR in some situations (not unlike how the JVM backend can be improved to produce better bytecode).

You may lose efficiency of your tests, however.

---

As you see, in general the answer is "probably nothing will happen, but we don't make any guarantee in that direction".

[rossabaker]

I'm weakly 👍 because we are fundamental, and it maximizes user flexibility without drag on us. But I've never once heard of users finding themselves in the muck because of a Scala.js upgrade, so I won't cry if it's closed.