Update Scala.js to 1.0, disable Scala.js coverage reporting

[travisbrown]

This is like #3312, except:

• It disables coverage reporting on Scala.js, which was causing the buildJVM job to fail for some reason.
• It's 1.0.1 instead of 1.0.0.
• It doesn't change the scala.js-1.0-publish.sh script to work for 0.6.

If we decide someday that we need to publish a future release for Scala.js 0.6.x, I think we should add a new scala.js-0.6-publish.sh at that point, rather than repurposing the 1.0 one.

[travisbrown]

/cc @cquiroz

[cquiroz]

I guess this is the way to go. I'm a bit worried that not every lib is on scala.js 1.0 and that would limit reach, e.g. we depend on scalajs-react which isn't yet on 1.0.
I'll close my PR about this

[travisbrown]

This is green but note that the validateJS jobs are now incredibly slow. I'll take a look at this locally today.

[travisbrown]

@cquiroz I'm happy to publish for 0.6 if we decide that that's what's needed—I just don't really want to sign up for that in advance. Let's see when 2.2.0 comes out, etc. It's always easy to add a new cross-publishing script for 0.6.

[larsrh]

It looks like coverage isn't reported at all anymore?

[travisbrown]

@larsrh Oh, wow, what a mess. I might not get to this today, but I don't think there's any real hurry.

[larsrh]

After looking at the build logs, it seems Coverage is reported, it just doesn't make its way into a comment on this PR: https://codecov.io/gh/typelevel/cats/pull/3357

[codecov-commenter]

Codecov Report

Merging #3357 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #3357   +/-   ##
=======================================
  Coverage   91.64%   91.64%           
=======================================
  Files         381      381           
  Lines        8268     8268           
  Branches      227      225    -2     
=======================================
  Hits         7577     7577           
  Misses        691      691           

Flag	Coverage Δ
#scala_version_212	91.63% <ø> (ø)
#scala_version_213	91.43% <ø> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6f27f07...36caae6. Read the comment docs.

[travisbrown]

Just refreshed this branch (I also went ahead and bumped the Scala.js version, so this supersedes #3418).

I confirmed that sbt clean validateJS doesn't run more slowly than master locally (3m17.515s vs. 3m51.507s, so actually a little faster).

I also confirmed that validateJS coverage is working locally for JVM modules (and there's a Codecov notification now), so I think this is ready to merge. @LukaJCB, @larsrh, @fthomas, mind a quick review?

[travisbrown]

The Scala.js builds are still slower in CI, and I'm not sure why, but I don't think that should block this PR.

[travisbrown]

Sorry, @ChristopherDavenport, @larsrh, just had to resolve a plugins.sbt conflict, so I'll need at least one re-review?

[travisbrown]

Ugh, now we're back to "builds take incredibly long or time out" instead of just "builds are slower". I asked about this in the Scala.js Gitter channel, but I think we'll have to hold off on this PR for now.

[travisbrown]

Capturing these comments from Sébastien on Gitter for the record:

Does ThisBuild / scalaJSLinkerConfig ~= { _.withCheckIR(false) } help?

used to take ~12 minutes now take 40+

hum that's probably not checkIR, now that I think of it.
It would be worth knowing exactly what step is slower, especially between you local build and the CI build.

Can you decompose the timings between theProject/test:fastOptJS and theProject/test? So that we know whether it is linking or actually running the tests which is slower. From the [info] Run completed in 12 minutes log line, I actually suspect the latter, but who knows.
If my guess is wrong and it's the former, could you output last just after running theProject/test:fastOptJS, to obtain the timings of individual steps inside linking?
If it's actually running the tests which is slower, one thing that's worth trying is whether disabling parallel testing helps (or makes it worse). That would be with Test / parallelExecution := false.

And:

You've got useless stuff there, but nothing harmful.
Your settings for scalaJSStage and jsEnv are the default ones, so you could remove those without changing anything.
Otherwise this is reasonable.

[travisbrown]

This is green again, and I'm going to go ahead and merge it. Just switching to FullOptStage cuts the test times way down (around 24 minutes in this run), and I think we can improve some other stuff, but that can happen in a follow-up PR.