cargo metadata: Machine-Readable Project Data
cargo metadata prints a JSON description of the workspace: packages, targets, features, dependencies, and resolved versions, for tools to consume.
When a CI script needs to know the crate list, target directory, or feature graph, parsing cargo metadata is far more reliable than scraping Cargo.toml by hand.
What it does
cargo metadata outputs a single JSON object describing every package in the workspace, their targets and features, the resolved dependency graph, and paths like target_directory and workspace_root. The schema is versioned via --format-version.
Common usage
cargo metadata --format-version 1 --no-deps
cargo metadata --format-version 1 | jq -r '.packages[].name'
cargo metadata | jq -r '.target_directory'Flags
| Flag | What it does |
|---|---|
| --format-version <n> | Pin the JSON schema version (use 1) |
| --no-deps | Only include workspace members, not all deps |
| --all-features / --features <x> | Resolve with the given features |
| --filter-platform <triple> | Resolve dependencies for one target |
| -q, --quiet | Suppress cargo status lines on stderr |
In CI
Always pass --format-version 1; without it cargo warns that the default version may change and could break your parser. Use --no-deps when you only need the workspace crates, which avoids resolving (and possibly downloading) the full graph and runs offline-friendly.
Common errors in CI
"warning: please specify --format-version flag explicitly to avoid compatibility problems" means add --format-version 1. If jq reports "parse error: Invalid numeric literal", cargo's status lines on stderr leaked into stdout; that should not happen, but redirect with 2>/dev/null to be safe. "error: failed to parse manifest" means a Cargo.toml is malformed.