I'm the process of cross-building UnivEq for Scala.JS 1.0.0-RC2. I've got jsdom installed in Travis and tests pass on the 0.6.31 builds, but fail on the 1.0.0-RC2 builds with TypeError: jsdom.createVirtualConsole is not a function.
Full error log: https://travis-ci.org/japgolly/univeq/jobs/636731705#L312
How to fix? Please help.
This happens because we never ported the additional support of jsdom v12 and later from the Scala.js 0.6.x branch (in this commit) to the newer, separate codebase for JSDOMNodeJSEnv at https://github.com/scala-js/scala-js-env-jsdom-nodejs. Apparently we forgot about that.
I have created a pull request at https://github.com/scala-js/scala-js-env-jsdom-nodejs/pull/33 to fix the issue.
Edit: the fix is now published as version 1.0.0-RC3. You can modify your project/plugins.sbt to depend on "org.scala-js" %% "scalajs-env-jsdom-nodejs" % "1.0.0-RC3" instead of ... % scalaJSVersion. It is compatible with Scala.js 1.0.0-RC2.
Obsolete old answer:
You could try using that new version today by checking out the master branch and publishing it locally:
$ git clone https://github.com/scala-js/scala-js-env-jsdom-nodejs.git
$ cd scala-js-env-jsdom-nodejs
$ sbt scalajs-env-jsdom-nodejs/publishLocal
$ cd ..
then using version 1.0.0-SNAPSHOT instead of 1.0.0-RC2 for scalajs-env-jsdom in your project/plugins.sbt
Related
What is the complete sbt command to build scala 2.12.16 distributable binary for *Nix system (macOS & Linux)?
Scala 2.12.16 source zip : https://github.com/scala/scala/archive/refs/tags/v2.12.16.zip
PS: sbt publishLocal builds scala compiler of latest stable version and then publishes to local ivy2 repo. So it is not helpful for me.
Thanks Seth Tisue for providing git repo information.
git repo for building scala distributable binary https://github.com/scala/scala-dist.git
sbt command universal:packageBin
Complete command to build scala 2.12.x binaries from sources:
git clone https://github.com/scala/scala-dist.git
cd scala-dist
git checkout 2.12.x
sbt clean universal:packageBin
after firing the above command binaries will be present in target/universal/scala-2.12.16.zip
in a build.sbt we can declare a range for a dependency; for example:
libraryDependencies += groupID %% "mylib" % "[2.0,)"
There are (in my case) multiple packages that fall within this range (I have 2.0.2, 2.0.3, 2.0.4 and even some more exotic versions like 2.0.1.dev and 2.0.3-dev of mylib available in my repository).
When I try to build this project, sbt consequently chooses version 2.0.2 for no apparent reason. I would expect him to take the biggest number within the range, but he never does. Here are the requirements I tried and the version he selected (so only when specifying an exact version number does he select a more recent version):
revision range | version selected
-----------------------------------------
[2.0,) | 2.0.2
[2.0.0,) | 2.0.2
]2.0,) | 2.0.2
2.0.+ | 2.0.2
latest.integration | 2.0.2
2.0.3 | 2.0.3
2.0.4 | 2.0.4
I have already tried the following workarounds:
removing the local ~/.sbt and ~/.ivy2 directories
running sbt -no-share -sbt-dir /tmp/sbt -ivy-dir /tmp/ivy to avoid any caching effect
searching my home directory for any file containing mylib in the name; only found ind ~/.ivy2
I have run most of my tests with sbt 0.13.16, but I have tried with 0.13.15 and 0.13.17
Note that all my builds run each time in a clean clone of my git repository; so no target directory remains.
the versions 2.0.2, 2.0.3 and 2.0.4 of mylib contain the same code and dependencies (I republished them for testing purposes)
The problem (for once) does not seem to reside in sbt.
I tried with sbt 1.2.1 and range 2.1.x. Now sbt complains that he cannot find this dependency; and he lists the available versions:
[warn] ==== my-maven-repo: tried
[warn] http://my-server/nexus/repository/my-repo/eu/company/mylib_2.12/[revision]/mylib_2.12-[revision].pom
[warn] [2.0.2, 2.0.2-dev.20180719.16.55.39.develop.dc3a706, 2.0.1-dev.20180719.16.49.57.develop.dc3a706, 2.0.1-dev.20180719.16.42.31.develop.dc3a706, 2.0.1.dev.20180719.16.31.59.develop.dc3a706]
so strangely he does not list all packages available on my nexus-maven repository.
After deleting one package using the nexus interface; it seems like this list was now complete.
So the real problem seems to be that sbt publish to a nexus repository does not recreate the index in that repository.
Workaround
I have created a custom sbt-publish-wrapper script to force nexus to recreate the repository metadata when publishing a new library:
#!/bin/bash
set -e
# just run sbt publish with the passed arguments as-is
sbt $# publish
# now make sure the repository on nexus is re-indexed
# this triggers a task to recreate metadata for all maven repositories. This task was manually configured in nexus.
# the id was obtained running `curl -v -u admin:***** -X GET http://my-company/nexus/service/rest/v1/tasks`
# the recreate-maven-repos needs only the nx-tasks-run privilege
curl -q -u recreate-maven-repos:recreate -X POST http://my-company/nexus/service/rest/v1/tasks/c42ab5f5-4bd6-4ed3-b2f1-d061c24a9b90/run
I can compile and run from sbt with a build.sbt file, e.g.,
scalaVersion := "2.11.11"
But once I add a Sonatype repo, e.g.,
resolvers += sonatypeRepo("releases")
the terminal is not properly reset and stops to echo input. I need to call reset after each call to sbt - any ideas what's causing this? I've already tried deleting ~/.ivy2, ~/.sbt, project and target - to no avail. I'm using sbt version 1.0.0, but it also happens with 0.13.x versions.
EDIT: Just found out that version 0.13.9 does not exhibit this behavior, so this seems to be a sbt regression.
Issue has been reported and being tracked in a couple of places as https://github.com/sbt/sbt/issues/3453 and
https://github.com/sbt/sbt/issues/3482
In lieu of an official patch/hotfix from SBT you can exercise one of these workarounds for now
stty echo (terminal/bash/shell)
reset (terminal/bash/shell)
use latest sbt-extras
I have a Play project that uses scala.js. Tests all ran fine until I upgraded the scala.js plugin to 0.6.13. Now I get "Error: Cannot find module '../moment'".
I read on the 0.6.13 release notes that run and test now use node.js by default; I'm sure that change is the root of my problem.
I see the note to install jsdom using "npm install jsdom" either locally or globally. I first tried installing the moment library globally (npm install -g moment). No change, so I tried installing in the project's root directory. Still no change.
Suggestions?
I updated the moment.js facade from "io.github.widok" %%% "scala-js-momentjs" % "0.2.0" to "ru.pavkin" %%% "scala-js-momentjs" % "0.4.1". Changed relevant import statements and recompiled. Tests passed.
Removed the node_modules directory from the app's root directory. Tests failed with the earlier error. Reinstalled the moment library (npm install moment) and tests pass again.
I've configured SBT (0.11.0) to pull in a GitHub project as a dependency, as per my answer on this question here.
It works fine except that I can't seem to get SBT to re-compile my Git dependency when it gets updated. In other words: if I make an update to the dependency, push to Git and reload my project's SBT and run package, then SBT does not recompile the external Git dependency when compiling my project.
I've tried creating a new branch in my Git dependency (say, forcenew) and updating the branch in my SBT project configuration to use this:
lazy val depProject = RootProject(uri("git://github.com/me/dep-project.git#forcenew"))
But even this doesn't force a refresh. I'm a bit stumped - I can't even find where SBT puts the Git project to compile it (it doesn't seem to be in ~/.sbt/ or ~/.ivy2/)...
Any help greatly appreciated!
From: https://github.com/sbt/sbt/issues/335
this should be fixed in 0.12.0, just call "sbt update"
It was fixed in 0.12.0 so sbt update is enough, but got back in 13.0 -- for now, you have to wipe dependency from ~/.sbt/staging/ manually
You likely want to clear out ~/.sbt/staging/
A quick hack you can add to your build.sbt:
def removegit = Command.command("removegit"){state =>
val home = sys.env("HOME")
val k = ("rm -rf "+ home + "/.sbt/0.13/staging/").!
state
}
commands ++= Seq(removegit)
And then sbt removegit will wipe that directory. This doesn't do anything smart like checking commits, which would be a great upgrade... The repos are being stored in ~/.sbt/0.13/staging/ on my machine, you may need to adjust that.