Installation & IDE Support

Although the Mill example projects come with their own ./mill bootstrap script, you can also download it manually:

Downloading a mill bootstrap script to the root of your project repository helps make it easier for new contributors to build your project, as they don’t have to install Mill before they can start. Anyone who wants to work with the project can simply use the ./mill script directly.

In general, bootstrap scripts are the recommended way of installing Mill. Similar to ./gradlew or ./mvnw, the ./mill bootstrap script reduces the chance of errors due to the installed version of Mill being incompatible with the version expected by your build. In-project bootstrap scripts are also useful for running Mill in CI/CD, ensuring that your build server like Jenkins or Github Actions has the correct version of Mill present to build, compile or test your code.

If you are starting a new project using a Mill bootstrap script, you can use the mill init to initialize the project folder with one of the Mill example projects. There are a wide range of example projects, from hello-world to multi-module libraries to client-server web applications, and you can pick one most similar to what you are doing so you can hit the ground running working.

Mill supports IntelliJ and VSCode and in general any client of the standard Build Server Protocol (BSP).

To prepare your project for IDEs, and in general any BSP client, you can run this command to generate the BSP configuration files:

Your IDEs may already auto-detect the Mill project and run this command on behalf of you, when opening/importing the project.

Typically, most Mill projects use a .mill-version file to configure what version to use. You can update the version specified in this file in order to change the version of Mill. The file path .config/mill-version is also supported. If neither is provided, the ./mill bootstrap script will use the DEFAULT_MILL_VERSION it has built in.

To choose a different Mill version on an ad-hoc basis, e.g. for experimentation, you can pass in a MILL_VERSION environment variable, e.g.

or

to override the Mill version manually. This takes precedence over the version specified in ./mill, .config/mill-version or .mill-version

Under some circumstances (e.g. corporate firewalls), you may not have access maven central. The typical symptom will be error messages which look like this;

It is expected that basic commands (e.g. clean) will not work, as Mill saying it is unable to resolve it’s own, fundamental, dependencies. Under such circumstances, you will normally have access to some proxy, or other corporate repository which resolves maven artifacts. The strategy is simply to tell mill to use that instead.

The idea is to set an environment variable COURSIER_REPOSITORIES (see coursier docs). The below command should pass the environment variable to the mill command.

If you are using bootstrap script, a more permanent solution could be to set the environment variable at the top of the bootstrap script, or as a user environment variable etc.

If your project is hosted on GitHub, GitLab, or Bitbucket, you can use Scala Steward to automatically open a pull request to update your Mill version (in .mill-version or .config/mill-version file), whenever there is a newer version available.

In case you want to try out the latest features and improvements that are currently in the main branch, unstable versions of Mill are available as binaries named #.#.#-n-hash linked to the latest tag.

The easiest way to use a development release is to use one of the Bootstrap Scripts, which support overriding Mill versions via an MILL_VERSION environment variable or a .mill-version or .config/mill-version file.