Scala CLI is an experimental tool to run/compile/test Scala that aims at being a better scala
command. It shares some similarities with build tools, but doesn't aim at supporting multi-module projects, nor to be extended via a task system.
User-facing documentation can be found on our website: scala-cli.virtuslab.org.
Building Scala CLI requires:
- a JVM (>= 8)
The Scala CLI sources ship with Mill launchers, so that Mill itself doesn't need to be installed on your system.
./mill -i scala …arguments…
./mill 'build[_].test'
./mill integration.jvm.test
Filter test suites with
./mill integration.jvm.test 'scala.cli.integration.RunTests.*'
./mill integration.jvm.test 'scala.cli.integration.RunTests.Multiple scripts'
(generating the launcher can take several minutes)
./mill integration.native.test
Build native packagers:
deb
for linuxmsi
for windowsdmg
andpkg
for macOS
(generating native packager for specified format)
./mill -i scala package ..arguments... --deb --output 'path.deb'
./mill -i scala package ..arguments... --dmg --output 'path.dmg'
./mill -i scala package ..arguments... --pkg --output 'path.pkg'
./mill mill.contrib.Bloop/install
Then run the command "Metals: Connect to build server".
(Recommended over the Metals import project functionality.)
Whenever the build is updated, just do these two steps again.
./mill mill.scalalib.GenIdea/idea
Then open the scala-cli directory in IntelliJ.
(Recommended over the IntelliJ import project functionality.)
Whenever the build is updated, run the command above again. IntelliJ should then pick up the new changes.
./mill -i show cli.nativeImage
This prints the path to the generated native image.
The file named scala
at the root of the project should also
be a link to it. (Note that the link is committed and is always there,
whether the files it points at exists or not.)
./mill -i show cli.launcher
This prints the path to the generated launcher. This launcher is a JAR, that directly re-uses the class directories of the modules of the project (so that cleaning up those classes will break the launcher). If this is a problem (if you wish to run the launcher on another machine or from a Docker image for example), use a native launcher (see above) or a standalone JVM one (see below).
./mill -i show cli.standaloneLauncher
This prints the path to the generated launcher. This launcher is a JAR, that embeds JARs of the scala-cli modules, and downloads their dependencies from Maven Central upon first launch (using the coursier cache, just like a coursier bootstrap).
The Scala CLI website is built with Docusaurus and uses Infima for styling.
cd website
yarn build
npm run serve
cd website
yarn run start
We have a built-in tool to validate .md
files called Sclicheck. To check all douments (and this is what we run on CI) run:
.github/scripts/check_docs.sh
You can also check single documents or directories using
.github/scripts/check_docs.sh <file> <dir>
To debug failing document, Sclicheck has build-in following options: --step
(stop after each command) or --stopAtFailure
(to stop after a failure). To debug getting started guide run following command:
.github/scripts/check_docs.sh --stopAtFailure docs/getting_started.md
Package with various logos for scala-cli can be found on google drive
There is a script scala-cli-src
in the repository root that is intended to work exactly like released scala-cli, but using a binary compiled the worktree.
Just add it to your PATH to get the already-released-scala-cli experience.
Instructions on how to release - Release Procedure