Cargo Workspaces: Monorepos in Rust

21 min read

A Cargo workspace lets several related crates live in one repository, share a single Cargo.lock and target/ directory, and be built/tested together. It is Rust’s answer to the npm workspaces / Lerna / Nx / Turborepo monorepo you have probably wrestled with in the JavaScript world — but it is built into the toolchain, with no extra dependency.

Quick Overview

When a project outgrows a single crate — say a shared core library, a command-line interface, and a web server that all reuse the same domain types — you reach for a workspace. You declare it with a [workspace] table in a top-level Cargo.toml that lists its members. Every member is a normal crate with its own Cargo.toml, but they share one resolved dependency graph (Cargo.lock), one build cache (target/), and can depend on each other by path. For a TypeScript/JavaScript developer this is exactly the monorepo pattern ("workspaces": ["packages/*"] in a root package.json), and the payoff is the same: atomic cross-package changes, one install/build, and no version-skew between internal packages.

TypeScript/JavaScript Example

A typical npm-workspaces monorepo for a task tracker has a private root package.json that lists the packages, plus one package.json per package. Local packages depend on each other by name:

1
// package.json  (the repo root — private, not published)
2
{
3
  "name": "taskhub",
4
  "private": true,
5
  "workspaces": ["packages/*"]
6
}

1
// packages/core/package.json  — the shared library
2
{
3
  "name": "@taskhub/core",
4
  "version": "0.3.0",
5
  "main": "index.js"
6
}

1
// packages/cli/package.json  — depends on the local @taskhub/core
2
{
3
  "name": "@taskhub/cli",
4
  "version": "0.3.0",
5
  "dependencies": { "@taskhub/core": "0.3.0" }
6
}

A single npm install at the root resolves everything into one root package-lock.json and symlinks the local packages into the root node_modules/:

1
$ npm install
2
$ find . -name package-lock.json
3
./package-lock.json                 # one lockfile at the root
4
$ ls -la node_modules/@taskhub
5
core -> ../../packages/core         # local packages symlinked, not copied
6
cli  -> ../../packages/cli

That single shared lockfile and the symlinked local packages are the two defining traits of a JavaScript monorepo. Cargo workspaces give you both — by design, not by convention.

Rust Equivalent

The same project as a Cargo workspace. The repo root holds a Cargo.toml with no [package] — only a [workspace] table (this is called a virtual manifest). Each member crate lives in its own directory with its own manifest.

The layout:

1
taskhub/
2
├── Cargo.toml          # the workspace root (virtual manifest — no [package])
3
├── Cargo.lock          # ONE shared lockfile for the whole workspace
4
├── target/             # ONE shared build cache for the whole workspace
5
└── crates/
6
    ├── core/           # taskhub-core: the shared library crate
7
    │   ├── Cargo.toml
8
    │   └── src/lib.rs
9
    └── cli/            # taskhub-cli: a binary that depends on core
10
        ├── Cargo.toml
11
        └── src/main.rs

The root manifest:

1
# taskhub/Cargo.toml  — the workspace root
2
[workspace]
3
resolver = "3"
4
members = ["crates/core", "crates/cli"]
5

6
# Fields every member can inherit, declared once.
7
[workspace.package]
8
version = "0.3.0"
9
edition = "2024"
10
license = "MIT OR Apache-2.0"
11
authors = ["Ada Zeybek <me@zeybek.dev>"]
12

13
# Dependency versions declared once, used by every member.
14
[workspace.dependencies]
15
serde = { version = "1.0", features = ["derive"] }
16
serde_json = "1.0"
17
anyhow = "1"
18
taskhub-core = { path = "crates/core" }

The shared library member:

1
[package]
2
name = "taskhub-core"
3
version.workspace = true        # inherit from [workspace.package]
4
edition.workspace = true
5
license.workspace = true
6
authors.workspace = true
7

8
[dependencies]
9
serde = { workspace = true }    # inherit the version + features from the root

1
use serde::{Deserialize, Serialize};
2

3
/// A single task tracked by the hub.
4
#[derive(Debug, Clone, Serialize, Deserialize)]
5
pub struct Task {
6
    pub id: u32,
7
    pub title: String,
8
    pub done: bool,
9
}
10

11
impl Task {
12
    pub fn new(id: u32, title: impl Into<String>) -> Self {
13
        Task { id, title: title.into(), done: false }
14
    }
15
}
16

17
/// Count how many tasks are still open.
18
pub fn open_count(tasks: &[Task]) -> usize {
19
    tasks.iter().filter(|t| !t.done).count()
20
}

The binary member that depends on the library:

1
[package]
2
name = "taskhub-cli"
3
version.workspace = true
4
edition.workspace = true
5
license.workspace = true
6
authors.workspace = true
7

8
[dependencies]
9
taskhub-core = { workspace = true }   # the local path dep, declared at the root
10
serde_json = { workspace = true }
11
anyhow = { workspace = true }

1
use anyhow::{Context, Result};
2
use taskhub_core::{open_count, Task};
3

4
fn main() -> Result<()> {
5
    let mut tasks = vec![
6
        Task::new(1, "Write workspaces guide"),
7
        Task::new(2, "Verify every snippet"),
8
    ];
9
    tasks[1].done = true;
10

11
    let json = serde_json::to_string_pretty(&tasks)
12
        .context("failed to serialize tasks")?;
13
    println!("{json}");
14
    println!("{} task(s) still open", open_count(&tasks));
15
    Ok(())
16
}

Running the CLI member from the workspace root produces real output:

1
$ cargo run -p taskhub-cli --quiet
2
[
3
  {
4
    "id": 1,
5
    "title": "Write workspaces guide",
6
    "done": false
7
  },
8
  {
9
    "id": 2,
10
    "title": "Verify every snippet",
11
    "done": true
12
  }
13
]
14
1 task(s) still open

Note: The package is named taskhub-core (with a hyphen) but the crate you use in code is taskhub_core (with an underscore). Cargo maps hyphens in package names to underscores in the language. This mirrors how serde_json the crate corresponds to the serde_json import name.

Detailed Explanation

The `[workspace]` table and members

1
[workspace]
2
resolver = "3"
3
members = ["crates/core", "crates/cli"]

members is a list of directory paths (relative to the root). Each must contain a crate with its own Cargo.toml. Glob patterns work too: members = ["crates/*"] picks up every crate under crates/.
resolver = "3" opts into the version-3 feature resolver, which is the default for edition-2024 crates. In a workspace you set it once at the root because the resolver is workspace-wide; you cannot let individual members disagree. (Resolver 2 fixed long-standing issues where a build-time feature would leak into your runtime build; resolver 3 is its successor and the current default.)

A root Cargo.toml that contains only [workspace] (no [package]) is a virtual manifest. The root is not itself a crate — it is just the coordinator. You can also make the root both a package and a workspace by including a [package] table alongside [workspace] (a “root package”), but for monorepos the virtual-manifest style keeps responsibilities clean.

One `Cargo.lock`, one `target/`

This is the heart of why workspaces exist. Run any build command anywhere in the tree and Cargo produces exactly one lockfile and one build directory at the root:

1
$ cargo build --quiet
2
$ find . -name Cargo.lock -not -path './target/*'
3
./Cargo.lock          # exactly one, at the workspace root

Because every member resolves against the same Cargo.lock, two members can never accidentally pull in two different versions of serde. This is the version-skew problem that plagues JavaScript monorepos (where each package can hoist or nest a different copy in node_modules/); a Cargo workspace makes it structurally impossible. The shared target/ also means a dependency compiled for one member is reused by every other member — no rebuild per package.

Path dependencies between members

crates/cli depends on crates/core through a path dependency:

1
# declared once at the root:
2
[workspace.dependencies]
3
taskhub-core = { path = "crates/core" }

1
# used by the cli member:
2
[dependencies]
3
taskhub-core = { workspace = true }

A path dependency points at a sibling crate on disk rather than a registry. This is the direct analogue of a local package symlinked into node_modules/ by npm workspaces. Because it is a path (not a version range), edits to taskhub-core are picked up immediately by taskhub-cli — no publish, no npm link, no rebuild step you have to remember.

Workspace inheritance: `[workspace.package]` and `[workspace.dependencies]`

Two tables let you declare shared settings once and inherit them with .workspace = true:

[workspace.package] holds package metadata (version, edition, license, authors, repository, rust-version, …) that members opt into with version.workspace = true, edition.workspace = true, and so on. Bump the version once at the root and every member moves together.
[workspace.dependencies] centralizes dependency versions and features. A member writes serde = { workspace = true } and inherits the version = "1.0" and features = ["derive"] from the root. A member can still add extra features on top: serde = { workspace = true, features = ["rc"] }.

This solves a real JavaScript-monorepo pain point: keeping the version of a third-party dependency identical across every package. In npm you reach for tooling (syncpack, Nx constraints) to enforce it; in Cargo it is a first-class manifest feature.

Workspace-wide lints

You can also share lint configuration. Declare lints once at the root and have members opt in:

1
# root Cargo.toml
2
[workspace.lints.clippy]
3
unwrap_used = "warn"

1
# each member Cargo.toml
2
[lints]
3
workspace = true

With that in place, running Clippy on any member that calls .unwrap() surfaces the shared rule (real output, trimmed to the lint note):

1
warning: used `unwrap()` on an `Option` value
2
  = note: if this value is `None`, it will panic
3
  = help: consider using `expect()` to provide a better panic message
4
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unwrap_used

This is the Rust equivalent of a single root .eslintrc that every package extends.

Key Differences

Concept	npm workspaces (JavaScript)	Cargo workspaces (Rust)
Declared in	`"workspaces"` array in root `package.json`	`[workspace]` table in root `Cargo.toml`
Root is a package?	Yes (usually `"private": true`)	Often a virtual manifest (no `[package]` at all)
Local package linkage	Symlink into `node_modules/`	Path dependency (`{ path = "..." }`)
Lockfile	One root `package-lock.json`	One root `Cargo.lock` (enforced, not optional)
Build/output cache	Per-package, plus hoisting heuristics	One shared `target/` for the whole workspace
Version skew of shared deps	Possible (different copies can be nested)	Impossible — single resolved graph
Shared dependency versions	External tooling (syncpack, Nx)	Built-in `[workspace.dependencies]`
Shared metadata	Manual or tooling	Built-in `[workspace.package]` inheritance
Run a task in one package	`npm run build -w @taskhub/cli`	`cargo build -p taskhub-cli`
Run a task everywhere	`npm run build --workspaces`	`cargo build --workspace`
Task orchestration	Turborepo / Nx / Lerna for caching + ordering	Cargo computes the build DAG itself; no extra tool

The biggest conceptual shift: a JavaScript monorepo is an opt-in pattern layered on top of npm with help from extra tooling, whereas a Cargo workspace is a native concept the compiler and build system understand directly. There is no Rust equivalent of Turborepo because Cargo already knows the dependency graph between your crates and builds them in the right order with shared caching out of the box.

Tip: Selecting members on the command line uses -p / --package (one crate) or --workspace / --all (every member). The flags mirror npm’s -w <name> and --workspaces.

Common Pitfalls

Pitfall 1: Putting `[profile.*]` in a member crate

Profiles ([profile.release], etc.) are workspace-wide and may only live in the root manifest. Add one to a member and Cargo ignores it with a warning. Adding [profile.release] to crates/core/Cargo.toml and building produces this real warning:

1
warning: profiles for the non root package will be ignored, specify profiles at the workspace root:
2
package:   /path/to/taskhub/crates/core/Cargo.toml
3
workspace: /path/to/taskhub/Cargo.toml

Fix: move every [profile.*] table to the root Cargo.toml. The same rule applies to the [patch] and [replace] tables — they are workspace-global.

Pitfall 2: Inheriting a dependency that the root never declared

If a member writes regex = { workspace = true } but the root [workspace.dependencies] has no regex entry, the workspace fails to load. The real error:

1
error: failed to load manifest for workspace member `/path/to/taskhub/crates/cli`
2
referenced by workspace at `/path/to/taskhub/Cargo.toml`
3

4
Caused by:
5
  failed to parse manifest at `/path/to/taskhub/crates/cli/Cargo.toml`
6

7
Caused by:
8
  error inheriting `regex` from workspace root manifest's `workspace.dependencies.regex`
9

10
Caused by:
11
  `dependency.regex` was not found in `workspace.dependencies`

Fix: add regex = "1" to [workspace.dependencies] at the root first, then inherit it in the member with regex = { workspace = true }.

Pitfall 3: Listing a member that does not exist yet

The root manifest validates every listed member before any command runs. If members = ["crates/core", "crates/cli"] but crates/cli/ has no Cargo.toml yet, every cargo command in the workspace fails:

1
failed to load manifest for workspace member `/path/to/taskhub/crates/cli`
2
referenced by workspace at `/path/to/taskhub/Cargo.toml`
3

4
Caused by:
5
  failed to read `/path/to/taskhub/crates/cli/Cargo.toml`
6

7
Caused by:
8
  No such file or directory (os error 2)

Fix: create the member crate before adding it to members, or use a glob (members = ["crates/*"]) so only existing directories are picked up. When scaffolding with cargo new, create the crate first; Cargo writes the new package without a [workspace] table because it detects it sits inside an existing workspace.

Pitfall 4: `cargo run` in a workspace with several binaries

In a single-crate project cargo run “just works.” In a workspace with more than one runnable binary it cannot guess which one you mean:

1
$ cargo run
2
error: `cargo run` could not determine which binary to run. Use the `--bin` option to specify a binary, or the `default-run` manifest key.
3
available binaries: taskhub-cli, taskhub-web

Fix: disambiguate with cargo run -p taskhub-cli, or set default-members = ["crates/cli"] in the root [workspace] so bare cargo run/cargo test target your usual crate.

Pitfall 5: Expecting `cargo new mypkg` to “add to the workspace” loudly

Coming from npm init -w packages/foo, you might expect explicit confirmation. cargo new crates/foo inside a workspace simply creates the crate and relies on your members list (or a glob) to include it — it does not print an “added to workspace” notice, and it deliberately omits a [workspace] table from the new child. If you used an explicit members = [...] list, remember to append the new path yourself.

Best Practices

Use a virtual manifest for monorepos. A root Cargo.toml with only [workspace] keeps the root from accidentally becoming a publishable crate and makes the “this directory coordinates crates” intent obvious.
Centralize versions in [workspace.dependencies]. Declare every third-party crate’s version once at the root and inherit it everywhere with { workspace = true }. This is the single most valuable workspace feature for avoiding version drift.
Inherit shared metadata via [workspace.package]. Put version, edition, license, and rust-version at the root and use .workspace = true in members so a single edit moves the whole workspace.
Prefer glob members (crates/*) for fast-growing repos, and an explicit list when you want tight control over what builds.
Set default-members to the crate(s) you run most so bare cargo run/cargo test do the obvious thing.
Keep [profile.*], [patch], and [replace] at the root only — they are workspace-global by definition.
Commit the single root Cargo.lock. For a workspace that ships applications/binaries this is the right call (reproducible builds); a workspace that publishes only libraries follows the usual library lockfile convention. See cargo.md.
Reach for a workspace when crates share code or ship together — a CLI plus its library, a server plus shared domain types, a proc-macro crate plus the crate that uses it. Do not split a single cohesive crate into a workspace prematurely.

Warning: All members compile against one feature-unified dependency graph. If member A enables a heavy feature of a shared dependency, member B is built with that feature too (resolver 3 mitigates build-vs-normal leakage, not enabling-across-members). Keep heavyweight optional features behind crates that not every member depends on.

Real-World Example

A production-flavored three-crate workspace: a shared taskhub-core library, a taskhub-cli binary, and a taskhub-web binary stub. Because there are two binaries, default-members points bare commands at the CLI. Everything below was compiled and run as-is.

1
# taskhub/Cargo.toml  — workspace root (virtual manifest)
2
[workspace]
3
resolver = "3"
4
members = ["crates/core", "crates/cli", "crates/web"]
5
default-members = ["crates/cli"]
6

7
[workspace.package]
8
version = "0.3.0"
9
edition = "2024"
10
license = "MIT OR Apache-2.0"
11
authors = ["Ada Zeybek <me@zeybek.dev>"]
12

13
[workspace.dependencies]
14
serde = { version = "1.0", features = ["derive"] }
15
serde_json = "1.0"
16
anyhow = "1"
17
taskhub-core = { path = "crates/core" }

Build the entire workspace at once:

1
$ cargo build --workspace
2
   Compiling taskhub-cli v0.3.0 (/path/to/taskhub/crates/cli)
3
   Compiling taskhub-web v0.3.0 (/path/to/taskhub/crates/web)
4
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 4.92s

Test every member in one shot:

1
$ cargo test --workspace
2
   Compiling taskhub-core v0.3.0 (/path/to/taskhub/crates/core)
3
   Compiling taskhub-cli v0.3.0 (/path/to/taskhub/crates/cli)
4
   Compiling taskhub-web v0.3.0 (/path/to/taskhub/crates/web)
5
     Running unittests src/lib.rs (target/debug/deps/taskhub_core-...)
6
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
7
     Running unittests src/main.rs (target/debug/deps/taskhub_cli-...)
8
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
9
     Running unittests src/main.rs (target/debug/deps/taskhub_web-...)
10
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

Inspect the unified dependency graph with cargo tree — note that taskhub-core appears as a path dependency of the CLI, exactly like a symlinked local package would in node_modules/ (real output, trimmed):

1
$ cargo tree -p taskhub-cli
2
taskhub-cli v0.3.0 (/path/to/taskhub/crates/cli)
3
├── anyhow v1.0.102
4
├── serde_json v1.0.150
5
│   ├── itoa v1.0.18
6
│   ├── memchr v2.8.1
7
│   ├── serde_core v1.0.228
8
│   └── zmij v1.0.21
9
└── taskhub-core v0.3.0 (/path/to/taskhub/crates/core)
10
    └── serde v1.0.228
11
        ├── serde_core v1.0.228
12
        └── serde_derive v1.0.228 (proc-macro)

Because the entire graph resolves once into the root Cargo.lock, taskhub-cli and taskhub-web are guaranteed to use the same serde build — the version-skew problem simply cannot occur.

Tip: cargo metadata --format-version 1 reports workspace_root and workspace_members as machine-readable JSON — the analogue of parsing a root package.json’s workspaces field with jq, but with the full resolved graph included.

Exercises

Exercise 1: Turn two crates into a workspace

Difficulty: Beginner

Objective: Create a virtual-manifest workspace whose binary depends on its sibling library by path.

Instructions: Make a taskhub/ directory with a root Cargo.toml (no [package]) listing two members, crates/core (a library) and crates/cli (a binary). Have cli call a function exported from core. Run cargo run -p taskhub-cli and confirm there is exactly one Cargo.lock at the root.

Solution

1
[workspace]
2
resolver = "3"
3
members = ["crates/core", "crates/cli"]

1
[package]
2
name = "taskhub-core"
3
version = "0.1.0"
4
edition = "2024"

1
pub fn greeting(who: &str) -> String {
2
    format!("hello from {who}")
3
}

1
[package]
2
name = "taskhub-cli"
3
version = "0.1.0"
4
edition = "2024"
5

6
[dependencies]
7
taskhub-core = { path = "../core" }

1
fn main() {
2
    println!("{}", taskhub_core::greeting("workspace"));
3
}

Build and verify the single lockfile:

1
$ cargo run -p taskhub-cli --quiet
2
hello from workspace
3
$ find . -name Cargo.lock -not -path './target/*'
4
./Cargo.lock

One Cargo.lock at the root is the proof that both members share a single resolved dependency graph.

Exercise 2: Centralize versions with `[workspace.dependencies]`

Difficulty: Intermediate

Objective: Declare a third-party crate’s version once at the root and inherit it in two members, plus inherit shared package metadata.

Instructions: Extend the workspace so the root declares serde (with the derive feature) and the shared version/edition in [workspace.package]. Both members inherit them with { workspace = true } / .workspace = true. Make core derive Serialize on a struct and cli serialize it. Fill in the /* ??? */ placeholders.

1
[workspace]
2
resolver = "3"
3
members = ["crates/core", "crates/cli"]
4

5
[workspace.package]
6
version = "0.2.0"
7
edition = "2024"
8

9
[workspace.dependencies]
10
serde = /* ??? */                 # version "1.0" with the "derive" feature
11
serde_json = "1.0"
12
taskhub-core = { path = "crates/core" }

1
[package]
2
name = "taskhub-core"
3
version.workspace = true
4
edition.workspace = true
5

6
[dependencies]
7
serde = /* ??? */                 # inherit from the workspace

1
use serde::Serialize;
2

3
#[derive(/* ??? */)]
4
pub struct Task {
5
    pub id: u32,
6
    pub title: String,
7
}

Solution

1
[workspace]
2
resolver = "3"
3
members = ["crates/core", "crates/cli"]
4

5
[workspace.package]
6
version = "0.2.0"
7
edition = "2024"
8

9
[workspace.dependencies]
10
serde = { version = "1.0", features = ["derive"] }
11
serde_json = "1.0"
12
taskhub-core = { path = "crates/core" }

1
[package]
2
name = "taskhub-core"
3
version.workspace = true
4
edition.workspace = true
5

6
[dependencies]
7
serde = { workspace = true }

1
use serde::Serialize;
2

3
#[derive(Debug, Serialize)]
4
pub struct Task {
5
    pub id: u32,
6
    pub title: String,
7
}

1
[package]
2
name = "taskhub-cli"
3
version.workspace = true
4
edition.workspace = true
5

6
[dependencies]
7
taskhub-core = { workspace = true }
8
serde_json = { workspace = true }

1
use taskhub_core::Task;
2

3
fn main() {
4
    let task = Task { id: 1, title: "Centralize versions".into() };
5
    println!("{}", serde_json::to_string(&task).unwrap());
6
}

Real output:

1
$ cargo run -p taskhub-cli --quiet
2
{"id":1,"title":"Centralize versions"}

The win: serde’s version and the derive feature are declared in exactly one place. Add a third member that needs serde and it inherits the same line — no chance of one crate using serde 1.0 and another a different copy.

Difficulty: Advanced

Objective: Configure a workspace-wide Clippy lint that every member opts into, add a unit test to the library, and run all members’ tests together.

Instructions: Add a [workspace.lints.clippy] table at the root that sets unwrap_used = "warn", and have each member opt in with [lints] workspace = true. Add a #[test] to the library crate. Run cargo test --workspace, then run cargo clippy --workspace and observe the shared lint fire on a deliberate .unwrap().

Solution

1
# Cargo.toml (root)
2
[workspace]
3
resolver = "3"
4
members = ["crates/mathlib", "crates/calc"]
5

6
[workspace.package]
7
version = "0.1.0"
8
edition = "2024"
9

10
[workspace.dependencies]
11
mathlib = { path = "crates/mathlib" }
12

13
[workspace.lints.clippy]
14
unwrap_used = "warn"

1
[package]
2
name = "mathlib"
3
version.workspace = true
4
edition.workspace = true
5

6
[lints]
7
workspace = true

1
pub fn add(a: i64, b: i64) -> i64 {
2
    a + b
3
}
4

5
#[cfg(test)]
6
mod tests {
7
    use super::*;
8

9
    #[test]
10
    fn adds() {
11
        assert_eq!(add(2, 3), 5);
12
    }
13
}

1
[package]
2
name = "calc"
3
version.workspace = true
4
edition.workspace = true
5

6
[dependencies]
7
mathlib = { workspace = true }
8

9
[lints]
10
workspace = true

1
// crates/calc/src/main.rs — deliberately uses unwrap() to trip the shared lint
2
fn first_word(s: &str) -> Option<&str> {
3
    s.split_whitespace().next()
4
}
5

6
fn main() {
7
    let _ = mathlib::add(2, 3);
8
    let w = first_word("hello world");
9
    println!("{}", w.unwrap());
10
}

Run the whole workspace’s tests (real output, compile lines trimmed):

1
$ cargo test --workspace
2
     Running unittests src/main.rs (target/debug/deps/calc-...)
3

4
running 0 tests
5

6
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
7

8
     Running unittests src/lib.rs (target/debug/deps/mathlib-...)
9

10
running 1 test
11
test tests::adds ... ok
12

13
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
14

15
   Doc-tests mathlib
16

17
running 0 tests
18

19
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

Run Clippy and watch the shared lint fire on the .unwrap() in calc (real output, trimmed):

1
$ cargo clippy --workspace
2
warning: used `unwrap()` on an `Option` value
3
 --> crates/calc/src/main.rs:8:20
4
  |
5
8 |     println!("{}", w.unwrap());
6
  |                    ^^^^^^^^^^
7
  |
8
  = note: if this value is `None`, it will panic
9
  = help: consider using `expect()` to provide a better panic message
10
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unwrap_used
11
  = note: requested on the command line with `-W clippy::unwrap-used`

The single [workspace.lints.clippy] table is the Rust analogue of one root .eslintrc that every package extends — change the rule once and it applies across the monorepo.

Cargo Workspaces: Monorepos in Rust

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

The `[workspace]` table and members

One `Cargo.lock`, one `target/`

Path dependencies between members

Workspace inheritance: `[workspace.package]` and `[workspace.dependencies]`

Workspace-wide lints

Key Differences

Common Pitfalls

Pitfall 1: Putting `[profile.*]` in a member crate

Pitfall 2: Inheriting a dependency that the root never declared

Pitfall 3: Listing a member that does not exist yet

Pitfall 4: `cargo run` in a workspace with several binaries

Pitfall 5: Expecting `cargo new mypkg` to “add to the workspace” loudly

Best Practices

Real-World Example

Further Reading

Official documentation

Cross-links in this guide

Exercises

Exercise 1: Turn two crates into a workspace

Exercise 2: Centralize versions with `[workspace.dependencies]`

Cargo Workspaces: Monorepos in Rust

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

The [workspace] table and members

One Cargo.lock, one target/

Path dependencies between members

Workspace inheritance: [workspace.package] and [workspace.dependencies]

Workspace-wide lints

Key Differences

Common Pitfalls

Pitfall 1: Putting [profile.*] in a member crate

Pitfall 2: Inheriting a dependency that the root never declared

Pitfall 3: Listing a member that does not exist yet

Pitfall 4: cargo run in a workspace with several binaries

Pitfall 5: Expecting cargo new mypkg to “add to the workspace” loudly

Best Practices

Real-World Example

Further Reading

Official documentation

Cross-links in this guide

Exercises

Exercise 1: Turn two crates into a workspace

Exercise 2: Centralize versions with [workspace.dependencies]

Exercise 3: Share lints and run the whole workspace’s tests

The `[workspace]` table and members

One `Cargo.lock`, one `target/`

Workspace inheritance: `[workspace.package]` and `[workspace.dependencies]`

Pitfall 1: Putting `[profile.*]` in a member crate

Pitfall 4: `cargo run` in a workspace with several binaries

Pitfall 5: Expecting `cargo new mypkg` to “add to the workspace” loudly

Exercise 2: Centralize versions with `[workspace.dependencies]`