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.testFilter 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.testBuild native packagers:
debfor linuxmsifor windowsdmgandpkgfor 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/installThen 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/ideaThen 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.nativeImageThis 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.launcherThis 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.standaloneLauncherThis 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 servecd website
yarn run startWe 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