Harnesses

Harnesses wire Minimal to operate a codebase with specific tools and commands. When you name a harness in your minimal.toml file, high-level commands like minimal build just work. Additionally, your tasks inherit these familiar tools and semantics automatically.

Learn more about harnesses in the reference section.

Available harnesses

The Minimal Public Package Registry ships harnesses for most common languages and build systems:

Harness	Detected by	Build command
go	go.mod + go.sum	go build
rust	Cargo.toml	cargo build --release
pnpm	pnpm-lock.yaml	pnpm install && pnpm build
npm	package-lock.json	npm ci && npm run build
bun	bun.lock	bun install && bun run build
deno	deno.json	deno compile
uv	uv.lock, pyproject.toml	uv sync && uv build
pip	requirements.txt, setup.py	pip3 install --target ./build .
gradle	build.gradle	gradle build -x test
make	Makefile	./configure && make
meson	meson.build	meson setup && ninja
cmake	CMakeLists.txt	cmake && make
zig	build.zig	zig build -Doptimize=ReleaseSafe

Using a harness

Harnesses are declared in the [harness] section of your minimal.toml file.

[harness]
use = "<harness name>"

Any harness defined in your codebase (or defined in any layer in your software supply chain) can be used.

When a harness is defined, any task will inherit the packages, default tasks, and other wiring declared in the harness.

Declaring additional dependencies

It's quite common for a specific codebase to need additional dependencies, either during the build (build packages) or on any system the built software runs (runtime packages). Both can be declared in your minimal.toml:

[harness]
use = "..."
build_packages = ["perl"]
runtime_packages = ["openssl"]

Dependencies can also be added automatically using the minimal add command.

Automatic initialization

Minimal will auto-detect the harness to use for most languages and package managers. To have the Minimal CLI detect an appropriate harness and pre-fill your codebase's minimal.toml file, run minimal init in the root directory.