Creates an anonymous Task. These depend on other tasks and be-depended-upon by other tasks, but cannot be run directly from the command line and do not perform any caching. Typically used as helpers to implement Task{...} targets.

Commands are only NamedTasks defined using def foo() = Task.Command{...} and are typically called from the command-line. Unlike other NamedTasks, Commands can be defined to take arguments that are automatically converted to command-line arguments, as long as an implicit mainargs.TokensReader is available.

InputImpls, normally defined using Task.Input, are NamedTasks that re-evaluate every time Mill is run. This is in contrast to TargetImpls which only re-evaluate when upstream tasks change.

InputImpls are useful when you want to capture some input to the Mill build graph that comes from outside: maybe from an environment variable, a JVM system property, the hash returned by git rev-parse HEAD. Reading these external mutable variables inside a Task{...} TargetImpl will incorrectly cache them forever. Reading them inside a Task.Input{...} will re-compute them every time, and only if the value changes would it continue to invalidate downstream TargetImpls

The most common case of InputImpl is SourceImpl and SourcesImpl, used for detecting changes to source files.

Similar to Source, but only for a single source file or folder. Defined using Task.Source.

A specialization of InputImpl defined via Task.Sources, SourcesImpl uses PathRefs to compute a signature for a set of source files and folders.

This is most used when detecting changes in source code: when you edit a file and run mill compile, it is the Task.Sources that re-computes the signature for you source files/folders and decides whether downstream TargetImpls need to be invalidated and re-computed.

Worker is a NamedTask that lives entirely in-memory, defined using Task.Worker{...}. The value returned by Task.Worker{...} is long-lived, persisting as long as the Mill process is kept alive (e.g. via --watch, or via its default MillServerMain server process). This allows the user to perform in-memory caching that is even more aggressive than the disk-based caching enabled by PersistentImpl: your Worker can cache running sub-processes, JVM Classloaders with JITed code, and all sorts of things that do not easily serialize to JSON on disk.

Like PersistentImpl, The user defining a Worker assumes the responsibility of ensuring the implementation is idempotent regardless of what in-memory state the worker may have.

Persistent tasks are defined using the Task(persistent = true){...} syntax. The main difference is that while TargetImpl deletes the T.dest folder in between runs, PersistentImpl preserves it. This lets the user make use of files on disk that persistent between runs of the task, e.g. to implement their own fine-grained caching beyond what Mill provides by default.

Note that the user defining a Task(persistent = true) task is taking on the responsibility of ensuring that their implementation is idempotent, i.e. that it computes the same result whether there is data in T.dest. Violating that invariant can result in confusing mis-behaviors

Returns the implicit mill.api.Ctx.Args.args in scope.

T.dest is a unique os.Path (e.g. out/classFiles.dest/ or out/run.dest/) that is assigned to every Target or Command. It is cleared before your task runs, and you can use it as a scratch space for temporary files or a place to put returned artifacts. This is guaranteed to be unique for every Target or Command, so you can be sure that you will not collide or interfere with anyone else writing to those same paths.

T.env is the environment variable map passed to the Mill command when it is run; typically used inside a Task.Input to ensure any changes in the env vars are properly detected.

Note that you should not use sys.env, as Mill's long-lived server process means that sys.env variables may not be up to date.

Provides the .fork.async and .fork.await APIs for spawning and joining async futures within your task in a Mill-friendly manner.

Returns the implicit mill.api.Ctx.Home.home in scope.

T.log is the default logger provided for every task. While your task is running, System.out and System.in are also redirected to this logger. The logs for a task are streamed to standard out/error as you would expect, but each task's specific output is also streamed to a log file on disk, e.g. out/run.log or out/classFiles.log for you to inspect later.

Messages logged with log.debug appear by default only in the log files. You can use the --debug option when running mill to show them on the console too.

Report build results to BSP for IDE integration

Converts a Seq[Task[T]] into a Task[Seq[T]]

Report test results to BSP for IDE integration

Converts a Seq[T] into a Task[Seq[V]] using the given f: T => Task[V]

A variant of traverse that also provides the mill.api.Ctx to the function f

This is the os.Path pointing to the project root directory.

This is the preferred access to the project directory, and should always be preferred over os.pwd* (which might also point to the project directory in classic cli scenarios, but might not in other use cases like BSP or LSP server usage).