Depending on Scala.js libraries
To be able to use a Scala library in Scala.js, it has to be separately compiled for Scala.js. You then can add it to your library dependencies as follows:
%%% (instead of the usual
%%) which will add the current Scala.js version to the artifact name. This allows to
- Cross-publish libraries to different Scala.js versions
- Disambiguate Scala.js artifacts from their JVM counterparts
Some Scala.js core libraries (such as the Scala.js library itself) do not need the
%%% since their version number is the Scala.js version number itself.
Note that you can also use
%%% in a Scala/JVM project, in which case it will be the same as
%%. This allows you to use the same
libraryDependencies settings when cross compiling Scala/JVM and Scala.js.
jsDependencies mechanism should be considered deprecated.
Use scalajs-bundler instead.
Scala.js 1.x note: since Scala.js 1.x, this functionality is not part of the core Scala.js sbt plugin. Instead, it is provided by sbt-jsdependencies.
The rest of this section applies to Scala.js 0.6.x only. Scala.js 0.6.x has reached End of Life.
The Scala.js sbt plugin has
jsDependencies for this purpose. You can write:
This will make your project depend on the respective WebJar and include a file named
**/2.1.4/jquery.js in the said WebJar when your project is run or tested. We are trying to make the semantics of “include” to be as close as possible to writing:
jsDependencies and associated metadata (e.g. for ordering) are persisted in a file (called
JS_DEPENDENCIES) and shipped with the artifact your project publishes. For example, if you depend on the
scalajs-jquery package for Scala.js, you do not need to explicitly depend or include
jquery.js; this mechanism does it for you.
Scoping to a Configuration
You may scope
jsDependencies on a given configuration, just like for normal
When they do so, you have to specify explicitly the name under which they are exported in a CommonJS environment (such as Node.js), otherwise they won’t work when executed in Node.js.
This is the purpose of the
commonJSName directive, to be used like this:
which essentially translates to a prelude
when running with Node.js from sbt (with
Note that the dependee must be declared as explicit dependency elsewhere, but not necessarily in this project (for example in a project the current project depends on).
This will look for
myJSLibrary.js in the resources and include it. It is an error if it doesn’t exist. You may use ordering and scoping if you need.
in your project settings. The resulting file in the target folder will have the suffix