retain Scala.js in the community build? is it worth the effort?

[SethTisue]

(this is on my mind because of scala-js/scala-js#3805, which presents fresh difficulties for retaining Scala.js in the community build)

traditionally we have included Scala.js, but it's not obviously necessary. Scala.js has zero dependencies besides Scala itself, and it is a leaf project — nothing in the community build is downstream from it.

dbuild's forte is rewiring projects' dependencies to use freshly-built versions, but that doesn't apply here, so dbuild isn't buying us anything, particularly.

therefore the only value we're getting out of including Scala.js at all is that we get early notification when a merged PR in scala/scala breaks Scala.js

but there are caveats even there:

1. the community build now uses frozen project SHAs that are only advanced monthly or so, so we aren't always building the latest Scala.js, so the early notification isn't that early
2. the community build uses a fixed Scala SHA as well, and that SHA is only advanced every 1-2 weeks, so the early notification isn't so early in that respect either

perhaps we should consider alternatives.

in particular, I think maybe Scala.js should add "latest Scala {2.11, 2.12, 2.13} nightly" to its CI matrix. you can find out what the latest nightly is by looking in the scala/scala repo, or if you want to avoid churn and don't mind living with caveat 2, you could look in https://github.com/scala/community-build/blob/2.12.x/nightly.properties (and so on for the other branches)

an example of how that looks (this is copied from a Lightbend-internal repo; I intend to blog about it at some point):

resolvers += "scala-integration" at
  "https://scala-ci.typesafe.com/artifactory/scala-integration/"
def getNightly(branch: String): String = {
  val url = s"https://raw.githubusercontent.com/scala/community-builds/$branch/nightly.properties"
  val props = new java.util.Properties
  props.load(new java.net.URL(url).openStream)
  props.getProperty("nightly").ensuring(_ != null)
}
val scala211Nightly = settingKey[String]("Scala 2.11 nightly version")
scala211Nightly := getNightly("2.11.x")
val scala212Nightly = settingKey[String]("Scala 2.12 nightly version")
scala212Nightly := getNightly("2.12.x")
val scala213Nightly = settingKey[String]("Scala 2.13 nightly version")
scala213Nightly := getNightly("2.13.x")

crossVersion := CrossVersion.patch
// the oldest version numbers here are simply the oldest ones customers asked for
crossScalaVersions := Seq(
  ...
  scala211Nightly.value, scala212Nightly.value, scala213Nightly.value
)

@sjrd @gzm0 wdyt?

[sjrd]

Since we never got to support downstream Scala.js projects in the community build, Scala.js ended up being a leaf project indeed.

For me, the real benefit is the early detection. The fact that it's a few weeks behind is not really problem. "Early" is early enough as long as we detect regressions several weeks before a new minor version of Scala gets released. I am open to obtain these notifications in a different context than dbuild.

in particular, I think maybe Scala.js should add "latest Scala {2.11, 2.12, 2.13} nightly" to its CI matrix

That would cause our CI to be non-reproducible, which is a big no-no for me. However, we could perhaps set up a separate repo with nothing but a script that clones Scala.js, resolves the appropriate nightly of Scala, and tests the relevant stuff. Assuming we can get one run of that CI in the time limits of Travis CI or GitHub Actions, that would be fine.

[sjrd]

Well ... I did that: https://github.com/scala-js/scala-js-test-scala-nightly
Travis at https://travis-ci.org/scala-js/scala-js-test-scala-nightly

[SethTisue]

works for me! I left a breadcrumb about it at scala/scala-dev#648

okay to go ahead and remove Scala.js from this repo, then?

[sjrd]

Yes, let's remove it from this repo.

Thank you @SethTisue for all your help!