support Mill build tool

[halotukozak]

Mill is a fast, multi-language build tool for the JVM ecosystem (Scala, Java, Kotlin). It is increasingly popular as an alternative to SBT and Gradle due to its performance and simpler, type-safe configuration.

Relevant Links

• Official Website: https://mill-build.org/
• Dependency Documentation: [Mill Library Dependencies](https://mill-build.org/mill/javalib/dependencies.html)

Package Files and Syntax

Mill uses Scala-based configuration files, typically named build.sc (older versions) or build.mill (newer versions).

File Patterns:

• build.sc
• build.mill
• *.mill

Dependency Syntax Examples:
Mill uses a specific string interpolator for Maven dependencies:

1. Standard Maven Dependency:

//mill 0.x
def ivyDeps = Agg(mvn"org.slf4j:slf4j-api:1.7.30")

//mill 1.x
def mvnDeps = Seq(mvn"org.slf4j:slf4j-api:1.7.30")

2. Scala Cross-built Dependency (Double colon ::):

//mill 0.x
def ivyDeps = Agg(mvn"com.lihaoyi::fansi:0.5.1")

//mill 1.x
def mvnDeps = Seq(mvn"com.lihaoyi::fansi:0.5.1")

3. Variable-based versions:

val fansiVersion = "0.5.1"

//mill 0.x
def ivyDeps = Agg(mvn"com.lihaoyi::fansi:$fansiVersion")

//mill 1.x
def mvnDeps = Seq(mvn"com.lihaoyi::fansi:$fansiVersion")

Versioning & Datasource

• Datasource: maven (Artifacts are resolved from Maven Central or custom Maven repositories).
• Versioning: Standard Maven versioning rules.

Example Repositories

• [com-lihaoyi/mill](https://github.com/com-lihaoyi/mill) (Mill builds itself)
• [com-lihaoyi/Ammonite](https://github.com/com-lihaoyi/Ammonite)

[halotukozak]

also scalaVersion, scalaTestVersion, scoverageVersion should be supported. My config looks like this:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:recommended"
  ],
  "customManagers":  [
    {
      "customType": "regex",
      "managerFilePatterns": [
        "/(^|/)build\\.sc$/",
        "/(^|/)build\\.mill$/",
        "/\\.mill$/"
      ],
      "matchStrings": [
        "mvn\"(?<depName>[^: ]+:[^:]+):(?<currentValue>[^\"]+)\""
      ],
      "datasourceTemplate": "maven"
    },
    {
      "customType": "regex",
      "managerFilePatterns": [
        "/(^|/)build\\.sc$/",
        "/(^|/)build\\.mill$/",
        "/\\.mill$/"
      ],
      "matchStrings": [
        "def scalaTestVersion\\s*=\\s*\"(?<currentValue>\\d+\\.\\d+\\.\\d+)\""
      ],
      "depNameTemplate":  "org.scalatest:scalatest",
      "datasourceTemplate": "maven"
    },
    {
      "customType": "regex",
      "managerFilePatterns": [
        "/(^|/)build\\.sc$/",
        "/(^|/)build\\.mill$/",
        "/\\.mill$/"
      ],
      "matchStrings": [
        "def scalaVersion\\s*=\\s*\"(?<currentValue>\\d+\\.\\d+\\.\\d+)\""
      ],
      "depNameTemplate":  "scala/scala3",
      "datasourceTemplate": "github-releases",
      "versioningTemplate": "semver"
    },
    {
      "customType": "regex",
      "managerFilePatterns": [
        "/(^|/)build\\.sc$/",
        "/(^|/)build\\.mill$/",
        "/\\.mill$/"
      ],
      "matchStrings": [
        "def scoverageVersion\\s*=\\s*\"(?<currentValue>\\d+\\.\\d+\\.\\d+)\""
      ],
      "depNameTemplate":  "scoverage/scalac-scoverage-plugin",
      "datasourceTemplate": "github-releases",
      "versioningTemplate": "semver"
    },
    {
      "customType": "regex",
      "managerFilePatterns": [
        "/(^|/)build\\.sc$/",
        "/(^|/)build\\.mill$/",
        "/\\.mill$/"
      ],
      "matchStrings": [
        "//\\|\\s*mill-version:\\s*(?<currentValue>\\S+)"
      ],
      "depNameTemplate": "com-lihaoyi/mill",
      "datasourceTemplate": "github-releases"
    }
  ]
}

[github-actions[bot]]

Hi there,

You're asking us to support a new package manager. We need to know some basic information about this package manager first. Please copy/paste the new package manager questionnaire, and fill it out in full.

Once the questionnaire is filled out we'll decide if we want to support this new manager.

Good luck,

The Renovate team

[wstein]

New package manager questionnaire

Did you read our documentation on adding a package manager?

• I've read the adding a package manager documentation.

Note on the original post: a few details in the top comment are out of date. There is no generic *.mill glob — Mill discovers a fixed set of basenames. And mvnDeps/mvn" vs ivyDeps/ivy" is a version split (Mill 1.x vs 0.x), not a stylistic one. Corrected details below. Everything here was verified against Mill 1.1.7 (latest stable, 2026-06-21) and the com-lihaoyi/mill sources, not from memory.

Basics

What's the name of the package manager?

Mill — https://mill-build.org, https://github.com/com-lihaoyi/mill.

Strictly it's a build tool whose JVM modules declare Maven coordinates, in the same way sbt, gradle and maven already are in Renovate. It is not a new registry or resolver: dependency resolution is delegated entirely to coursier against ordinary Maven repositories.

What language(s) does this package manager support?

Mill 1.x ships toolchain modules for Java, Scala, Kotlin, Groovy, and Android (all Maven-resolved — this is the part relevant to Renovate), plus Python and JavaScript/TypeScript (which resolve via pip/npm, and which I'd suggest leaving out of scope for a first implementation).

Verified from libs/ in the Mill repo: androidlib, javalib, kotlinlib, groovylib, javascriptlib, pythonlib, scalalib, scalajslib, scalanativelib. No C/C++ support.

How popular is this package manager?

Numbers as of 2026-08-01:

Metric	Value
GitHub stars / forks	2,771 / 446
Contributors	249
Commits in last 12 months	1,099, from 49 distinct authors
Latest stable	1.1.7 (2026-06-21); 1.0.0 GA was 2025-07-10
Release cadence	median 8 days between the last 20 stable releases

GitHub code search (/search/code, totals are approximate and the index covers only a subset of public repos):

Query	total_count
filename:build.mill	1,368
filename:package.mill	788
filename:.mill-version	354
filename:build.sc "import mill"	1,692
"mvn\"" filename:build.mill (1.x syntax)	574
"ivy\"" filename:build.mill (0.x syntax)	212

Paginating filename:build.mill to the API's 1,000-result ceiling yielded 379 distinct repositories; extrapolating suggests roughly 500 repos with a build.mill. I want to be explicit that this is an estimate — the 1,000-result cap makes an exact count unobtainable.

The Scala Survey 2026 (1,056 respondents) puts Mill at 20% active users, behind sbt (80%) and scala-cli (~50%). Flagging that as a blog write-up, not primary data.

Notable adopters, each verified by checking for build.mill at the repo root:

• OpenXiangShan/XiangShan (7.2k ★), chipsalliance/chisel (4.7k ★), chipsalliance/t1, SpinalHDL/VexiiRiscv — Mill has become the de-facto build tool of the RISC-V / Chisel hardware ecosystem
• coursier/coursier (2.1k ★), VirtusLab/scala-cli (637 ★), almond-sh/almond (1.6k ★) — core Scala tooling, including a competing build tool that builds itself with Mill
• flix/flix (2.7k ★), databricks/sjsonnet, swaldman/c3p0 (1.3k ★, a pure-Java project)
• The whole com-lihaoyi library ecosystem: Ammonite, upickle, os-lib, requests-scala, fastparse, scalatags, cask, utest, pprint, mainargs, sourcecode, geny

Does this language have other (competing?) package managers?

• Yes (give names).
• No.

sbt, Maven, Gradle, Bazel, scala-cli, Bleep.

Worth noting for prioritisation: Renovate already has managers for sbt, gradle, gradle-wrapper, maven, maven-wrapper, bazel, bazelisk, scalafmt, leiningen, kotlin-script, ant, deps-edn, osgi and smithy. Mill is the one JVM build tool of any real adoption with no coverage. Its users currently have to hand-roll customManagers (see the regex config in the comment above), which works but silently misses the ::/::: cross-version forms and cannot resolve interpolated versions.

What are the big selling points for this package manager?

• Speed. Fine-grained task-level caching and parallelism; typically the headline reason people migrate off sbt.
• A simple, direct config model. Modules are plain objects and dependencies are plain defs, versus sbt's settings/scopes DSL. Concretely, this makes Mill files easier to statically extract from than build.sbt.
• One tool across languages. Java, Scala, Kotlin, Groovy and Android in one build.
• No lockfile. Versions live in the build file and nowhere else (see Artifacts below) — which is very good news for a Renovate manager.

Detecting package files

What kind of package files, and names, does this package manager use?

Mill discovers a fixed set of basenames, not a glob. Source of truth is core/constants/src/mill/constants/CodeGenConstants.java, and the list changed across versions:

Mill 1.1.x (current):

rootBuildFileNames   = List.of("build.mill.yaml", "build.mill");
nestedBuildFileNames = List.of("package.mill.yaml", "package.mill");

Mill 0.12.x and 1.0.x:

rootBuildFileNames   = {"build.mill", "build.mill.scala", "build.sc"};
nestedBuildFileNames = {"package.mill", "package.mill.scala", "package.sc"};

So the full set a manager should know about:

File	Role
build.mill	Root build (Mill 0.12+). Scala syntax.
package.mill	Per-subdirectory module config in a multi-module build. Scala syntax.
build.mill.yaml / package.mill.yaml	Declarative YAML builds, new in Mill 1.1.x. Plain YAML.
build.sc / package.sc	Legacy Mill 0.11-era names. Scala syntax. Dropped in 1.1.x.
build.mill.scala / package.mill.scala	Valid 0.12.x–1.0.x only. Rare — 6 code-search hits total.
mill-build/build.mill	Meta-build: configures how build.mill itself is compiled. Contains build-plugin deps.
mill-build/src/*.scala	Where projects conventionally hoist a Deps object of version constants.
.mill-version, .config/mill-version	Mill's own version, plain text one-liner.
.mill-jvm-version, .config/mill-jvm-version	JVM version, coursier syntax (temurin:17, zulu:25, system).
mill, mill.bat	Checked-in bootstrap launchers with a hardcoded DEFAULT_MILL_VERSION.

Which managerFilePatterns pattern(s) should Renovate use?

Suggested default:

managerFilePatterns: [
  '/(^|/)build\\.mill(\\.yaml|\\.scala)?$/',
  '/(^|/)package\\.mill(\\.yaml|\\.scala)?$/',
  '/(^|/)mill-build/src/[^/]*\\.scala$/',
  '/(^|/)\\.mill-version$/',
  '/(^|/)\\.config/mill-version$/',
],

build.sc / package.sc are deliberately omitted from the default — see the false-hits question. They could be added behind opt-in, or included with a content guard.

This mirrors the existing sbt manager's shape almost exactly (/\.sbt$/, /project/[^/]*\.scala$/, /project/build\.properties$/).

Do many users need to extend the managerFilePatterns pattern for custom file names?

• Yes, provide details.
• No.

Mill will not load a build file under any other name, so the set is closed by construction. The only likely extension is users opting build.sc back in for legacy repos.

Is the managerFilePatterns pattern going to get many "false hits" for files that have nothing to do with package management?

For build.mill / package.mill / .mill-version: essentially no. These names are Mill-specific.

For build.sc: yes, badly. build.sc is also the Ammonite script convention. Of 5,824 build.sc hits, only 1,692 (~29%) contain import mill. That's the reason for leaving it out of the default above.

There is a second, subtler false hit worth calling out: a build.mill in a repo does not mean the repo is built with Mill. I verified two real cases — OpenAPITools/openapi-generator (26.6k ★) builds with Maven and only has build.mill files as test fixtures under modules/openapi-generator-mill-plugin/example/; hail-is/hail has build.mill only in subdirectories. Since Renovate would update these as ordinary Maven coordinates the blast radius is small, but it argues for extractPackageFile returning null when a file yields no recognisable deps, as the docs recommend.

Parsing and Extraction

Can package files have "local" links to each other that need to be resolved?

Yes, and this is the main implementation difficulty. Two forms:

1. Module cross-references. package.mill files declare their path as a package (deps/package.mill starts with package build.deps) and modules reference each other as build.foo.bar. These are internal module deps — no lookup needed, just don't mistake them for external ones.

2. Version constants hoisted into shared Scala files. This is very common and matters a lot:

   // mill-build/src/Deps.scala
   object Deps { val zinc = "1.10.4"; val scalaVersion = "3.7.4" }

   // build.mill
   def mvnDeps = Seq(mvn"org.scala-sbt:compiler-interface:${Deps.zinc}")

   Mill's own build does exactly this. It's the same problem Gradle version catalogs and sbt's project/*.scala present, and the existing sbt manager already solves the simpler val fooVersion = "1.2.3" case in the same file.

Package file parsing method

The package files should be:

• Parsed together (in serial).
• Parsed independently.

extractAllPackageFiles, for the reason above — build.mill, package.mill and mill-build/src/*.scala share a variable namespace, and .mill-version needs pairing with the build file. Same rationale the sbt manager uses.

A reduced first version could use extractPackageFile and simply mark interpolated versions with a skipReason, then graduate later.

Which format/syntax does the package file use?

• JSON
• TOML
• YAML — for build.mill.yaml / package.mill.yaml, and for the //| build header
• Custom (explain below)

Scala 3, for build.mill / package.mill / *.sc. Dependencies appear inside a mvn"…" string interpolator.

Note the //| build header in Mill 1.x: a YAML 1.2 block at the top of build.mill where every line is prefixed //| :

//| mill-version: 1.1.7
//| mill-jvm-version: temurin:11
//| repositories:
//| - https://oss.sonatype.org/content/repositories/snapshots
//| mvnDeps:
//| - com.goyeau::mill-scalafix::0.5.1-14-4d3f5ea-SNAPSHOT

package build

So a single build.mill is YAML-in-comments followed by Scala. In build.mill.yaml the same content is plain YAML, with meta-build keys nested under a mill-build: section.

How should we parse the package files?

• Off the shelf parser.
• Using regex.
• Custom-parsed line by line.
• Other.

Regex for the Scala parts — full Scala parsing is out of scope, and the sbt manager sets the precedent that regex is sufficient here. Mill is actually easier to regex than sbt: deps are always inside a mvn"…" / ivy"…" interpolator, and Mill's own Dep.parse is itself just a split on : and ;.

An off-the-shelf YAML parser for build.mill.yaml / package.mill.yaml and the //| header block (strip the //| prefix, then parse).

Does the package file have different "types" of dependencies?

• Yes, production and development dependencies.
• No, all dependencies are treated the same.

...with an important caveat: Mill has no test scope. From the docs: "One difference between Mill and other build tools like sbt or Maven is the fact that tests are ordinary submodules on their own… There is no special test scope in Mill." Test dependencies live in the test submodule's own mvnDeps. So depType derives from the task name, and test deps are distinguished by the enclosing module, not the task.

Mill 1.x task	Mill 0.x name	Scope
mvnDeps	ivyDeps	compile + runtime, transitive
compileMvnDeps	compileIvyDeps	compile-only (≈ Maven provided), non-transitive
runMvnDeps	runIvyDeps	runtime-only, transitive
bomMvnDeps	bomIvyDeps	BOM import, not fetched
depManagement	—	version forcing / exclusions, not fetched
//| mvnDeps:	import $ivy	build-plugin deps (meta-build)

Plus these, which also carry real coordinates: mandatoryMvnDeps, scalacPluginMvnDeps, kotlincPluginMvnDeps, annotationProcessorsMvnDeps, kaptProcessorMvnDeps, errorProneMvnDeps.

List all the sources/syntaxes of dependencies that can be extracted

Coordinate grammar. From Dep.parse in libs/javalib/src/mill/javalib/Dep.scala — the colon count is significant and the parser rejects anything else:

Form	Meaning	Example
org:name:version	plain Java/Maven	mvn"org.slf4j:slf4j-api:1.7.25"
org:name	version from BOM / depManagement	mvn"io.grpc:grpc-protobuf"
org::name:version	Scala binary cross → _2.13 / _3	mvn"com.typesafe.akka::akka-actor:2.5.25"
org:::name:version	full Scala version cross → _2.12.12	mvn"org.scalamacros:::paradise:2.1.1"
org::name::version	binary cross + platform suffix — the Scala.js / Native form, → name_sjs1_3	mvn"org.scala-js::scalajs-dom::2.2.0"
org:::name::version	full cross + platform	rare
org:name::version	platform suffix only	rare

⚠️ org:name:version:classifier (the Gradle/Maven 4-part form) is NOT valid Mill — it throws. Classifiers use a ; attribute instead. The accepted attribute keys are a closed set: classifier, type, exclude, force.

mvn"io.netty:netty-tcnative-boringssl-static:2.0.65.Final;classifier=linux-x86_64"
mvn"com.google.protobuf:protoc:${v};classifier=$classifier;type=exe"
mvn"com.lihaoyi::pprint:0.5.3;exclude=com.lihaoyi:fansi_2.12"
mvn"com.lihaoyi::fansi:0.2.14;force"

Method-chained modifiers — all present on Dep, and all leave the version literal intact, so they only affect extraction if the regex is greedy:

.exclude(("org","name")), .excludeOrg(…), .excludeName(…), .forceVersion(), .withConfiguration(…), .optional(…), .withDottyCompat(scalaVersion())

Interpolated versions. Very common — not an edge case:

mvn"org.scala-native::nativelib::${scalaNativeVersion()}"
mvn"org.jetbrains.kotlin:kotlin-stdlib:${kotlinVersion()}"
mvn"com.lihaoyi::mill-libs:$millVersion"

Mill-specific placeholders that must be skipped, not bumped — Mill substitutes these itself:

//| mvnDeps: ["com.lihaoyi::mill-contrib-buildinfo:$MILL_VERSION"]
//| mvnDeps: ["de.tototec::de.tobiasroeser.mill.vcs.version_mill$MILL_BIN_PLATFORM:0.1.2"]

Non-library versions that are also worth updating:

Task / key	Datasource	Note
def scalaVersion	maven (org.scala-lang:scala3-compiler_3 / scala-library)	also needed as a constraint, see Lookup
def kotlinVersion	maven (org.jetbrains.kotlin:kotlin-stdlib)
def scalaJSVersion	maven (org.scala-js:scalajs-linker_2.13)
def scalaNativeVersion	maven (org.scala-native:nscplugin)
def jvmVersion	java-version	jvmId is the deprecated older name
.mill-version / //| mill-version:	maven (com.lihaoyi:mill-dist) or github-releases
//| mill-jvm-version:	java-version	system is a valid sentinel — skip it
DEFAULT_MILL_VERSION in mill / mill.bat	as above	analogous to gradle-wrapper

The original post's suggestion of github-releases on scala/scala3 for scalaVersion works but maven is more accurate, since that's what actually gets resolved.

Describe which types of dependencies above are supported and which will be implemented in future

Proposed first cut:

• ✅ mvn"…" and ivy"…" with all colon-count forms, in build.mill / package.mill / *.sc
• ✅ Literal versions; ;classifier= / ;type= attributes
• ✅ .mill-version, .config/mill-version, //| mill-version:
• ✅ build.mill.yaml / package.mill.yaml (plain YAML lists — arguably the easiest surface, could even ship first)
• ✅ //| mvnDeps: build-plugin deps, skipping $MILL_VERSION / $MILL_BIN_PLATFORM entries
• ⏳ Later: cross-file variable resolution from mill-build/src/*.scala; scalaVersion / kotlinVersion / JVM version; the mill launcher scripts; single-file scripts (a bare Foo.java with a //| header and no build file at all)
• ❌ Not planned: arbitrary Scala expressions in ${…}. The interpolator is a plain StringContext extension, so any expression is legal. These should get a skipReason.

Versioning

What versioning scheme does the package file(s) use?

Maven versioning, via coursier. Renovate's existing ivy versioning (what the sbt manager already uses) should be the right fit; maven versioning is the alternative.

Does this versioning scheme support range constraints, like ^1.0.0 or 1.x?

• Supports range constraints (for example: ^1.0.0 or 1.x), provide details.
• No.

Qualified answer. Mill passes the version string straight to coursier.version.VersionConstraint, so coursier's syntax applies mechanically: intervals [1.0,2.0), 2.0+, latest.release, latest.integration.

But I searched Mill's entire docs, examples and test suite and found zero interval or latest.* examples in any mvn"…" string. It's a capability of the underlying layer, not idiomatic Mill. In practice Mill builds pin exact versions. I'd suggest getRangeStrategy defaulting to "pin"-friendly behaviour and not over-engineering range support up front.

(One place latest.release is idiomatic: def jvmIndexVersion.)

Lookup

Is a new datasource required?

• Yes, provide details.
• No.

maven for everything library-shaped. java-version for jvmVersion / mill-jvm-version. Either maven (com.lihaoyi:mill-dist) or github-releases (com-lihaoyi/mill) for Mill itself — the sbt manager already sets the precedent of including github-releases "for sbt itself".

Will users want (or need to) set a custom host or custom registry for Renovate's lookup?

• Yes, provide details.
• No.

Corporate Nexus/Artifactory mirrors, and Sonatype snapshots. Same situation as the existing sbt and maven managers.

Where can Renovate find the custom host/registry?

• No custom host or registry is needed.
• In the package file(s), provide details.
• In some other file inside the repository, provide details.
• User needs to configure Renovate where to find the information, provide details.

Three distinct mechanisms, and they should not be conflated:

1. Per-module, in the build file — def repositories: T[Seq[String]]:

   object foo extends ScalaModule {
     def repositories = Seq("https://oss.sonatype.org/content/repositories/releases")
   }

   There is also def repositoriesTask: Task[Seq[Repository]] for programmatic coursier.Repository instances, which is not statically extractable — skip it.

2. Build-wide — the mill-repositories header key, or a .mill-repositories file:

   //| mill-repositories: ["https://oss.sonatype.org/content/repositories/releases"]

   Note this is different from the un-prefixed //| repositories: key, which configures only the meta-build (i.e. resolution of //| mvnDeps build plugins).

3. Outside the repo — coursier's mirror.properties (~/.config/coursier/mirror.properties on Linux, ~/Library/Preferences/Coursier/ on macOS), or COURSIER_MIRRORS. Renovate can't see these, so those users need registryUrls / hostRules in Renovate config.

Are there any constraints in the package files that Renovate should use in the lookup procedure?

• Yes, there are constraints on the parent language (for example: supports only Python v3.x), provide details.
• Yes, there are constraints on the parent platform.
• Yes, some other kind of constraint, provide details.
• No constraints.

scalaVersion is required to resolve :: deps at all. mvn"com.lihaoyi::fansi:0.5.1" is not a complete coordinate — the artifact name is fansi_3 or fansi_2.13 depending on def scalaVersion in the enclosing module. This is exactly the %% situation the sbt manager already handles.

::: needs the full Scala version (_2.12.12). ::…:: additionally needs the platform suffix from scalaJSVersion / scalaNativeVersion (_sjs1_3).

The complication versus sbt: scalaVersion is a per-module def and may be inherited from a parent trait or a mill-build/src/*.scala constant, so it isn't always in the same file as the dep. When it can't be resolved, a skipReason is the honest outcome.

Secondary: def jvmVersion bounds which artifact versions are usable, though I'd treat that as out of scope initially.

Will users need the ability to configure language or other constraints using Renovate config?

• Yes, provide details.
• No.

A way to supply scalaVersion when Renovate can't statically resolve it, for the inheritance case above. Otherwise the standard constraints mechanism should be enough.

Artifacts

Does the package manager use a lock file or checksum file?

• Yes, uses lock file.
• Yes, uses checksum file.
• Yes, uses lock file and checksum file.
• No lock file or checksum.

Definitively no. I checked this carefully, because it's the single most consequential answer here. Evidence: no lock/checksum files tracked anywhere in the Mill repo; zero occurrences of "lockfile"/"lock file" in the entire user-facing docs tree; LauncherLockRegistry.scala is an in-memory concurrency lock for launcher processes, unrelated to dependency resolution. Resolution is delegated to coursier with caching in ~/.cache/coursier, and build output goes to out/, which is gitignored.

Is the locksum or checksum mandatory?

• Yes, locksum is mandatory.
• Yes, checksum is mandatory.
• Yes, lock file and checksum are mandatory.
• No mandatory locksum or checksum.
• Package manager does not use locksums or checksums.

If lockfiles or checksums are used: what tool and exact commands should Renovate use to update one (or more) package versions in a dependency file?

N/A. updateArtifacts is not needed at all — Renovate never has to execute Mill, download a JVM, or spawn a child process. Editing the version string in the build file is the complete update. This makes Mill substantially cheaper to support than Gradle.

Package manager cache

Does the package manager use a cache?

• Yes, provide details.
• No.

Coursier's ~/.cache/coursier for resolved artifacts, and Mill's own out/ directory for build outputs. Neither is relevant to Renovate, since Renovate never runs Mill.

If the package manager uses a cache, how can Renovate control the cache?

• Package manager does not use a cache. (effectively — not one Renovate ever touches)
• Controlled via command line interface, provide details.
• Controlled via environment variables, provide details.

For completeness: coursier's cache honours COURSIER_CACHE, and Mill's output dir is out/.

Should Renovate keep a cache?

• Yes, ignore/disable the cache.
• No.

Generating a lockfile from scratch

• Yes, explain which command Renovate should use to generate the lockfile.
• No, the package manager does not generate a lockfile from scratch.
• No, the package manager does not use lockfiles.

supportsLockFileMaintenance should be false.

Other

What else should we know about this package manager?

The sbt manager is a near-exact structural template. The mapping is close enough that a Mill manager could plausibly be written by analogy:

sbt manager	Mill equivalent
*.sbt	build.mill, package.mill
project/*.scala (version constants)	mill-build/src/*.scala
project/build.properties → sbt.version=	.mill-version / //| mill-version:
"org" %% "name" % "ver"	mvn"org::name:ver"
% vs %% vs %%%	: vs :: vs ::…::
ivy versioning, maven datasource	same
github-releases for sbt itself	github-releases / maven for Mill itself
extractAllPackageFiles (serial)	same, for the same reason
No lockfile	No lockfile

The 0.x → 1.x migration is the main compatibility axis. Mill 1.0.0 (2025-07-10) renamed ivyDeps→mvnDeps (and compileIvyDeps→compileMvnDeps, etc.) with no deprecated alias — ivyDeps has zero occurrences in the 1.x source. It also removed import $ivy / import $file in favour of the //| header. Meanwhile mvn" was back-ported to 0.12.11 and ivy" still compiles in 1.x as a deprecated alias. So a manager must accept both interpolators everywhere but should expect ivyDeps-style task names only in 0.x files. Code search says the split is currently roughly 574 mvn" to 212 ivy" among build.mill files.

Agg(...) → Seq(...) also changed in 1.x, so the collection wrapper around the deps shouldn't be assumed.

Prior art inside Mill. Mill ships ./mill mill.javalib.Dependency/showUpdates, which does a coursier-based update check. Its own docs caveat it: "it uses heuristics based on common versioning schemes, so it may not work as expected for dependencies with particularly weird version numbers." It has no PR-raising capability, which is precisely the gap Renovate would fill.

Mill's own repo uses Dependabot, scoped only to github-actions — so Mill does not currently self-host any JVM dependency automation.

A pragmatic staging suggestion: build.mill.yaml / package.mill.yaml are plain YAML with a flat mvnDeps: list. If a minimal first PR is preferred, that surface plus .mill-version is small, unambiguous, and needs no Scala regex at all — though it's also the least-used surface today (Mill 1.1.x only), so the Scala path is where the actual user value is.