Dev-Dependencies, Build-Dependencies, and Optional Dependencies

19 min read

Quick Overview

In package.json you split packages into dependencies and devDependencies so test runners and bundlers don’t ship to production. Cargo makes the same split — and adds a third bucket for code that runs at build time — through three manifest tables: [dependencies], [dev-dependencies], and [build-dependencies]. On top of that, any normal dependency can be marked optional so it is only pulled in when a feature flag turns it on. This page is about which bucket a crate belongs in and when each one is compiled — a distinction Cargo enforces far more strictly than npm.

TypeScript/JavaScript Example

A typical package.json separates runtime code from tooling. The dependencies ship; the devDependencies are for building and testing only:

1
{
2
  "name": "id-gen",
3
  "version": "0.1.0",
4
  "type": "module",
5
  "dependencies": {
6
    "nanoid": "^5.0.0"
7
  },
8
  "devDependencies": {
9
    "vitest": "^2.0.0",
10
    "fast-check": "^3.0.0",
11
    "typescript": "^5.5.0"
12
  },
13
  "optionalDependencies": {
14
    "fsevents": "^2.3.0"
15
  }
16
}

How Node and npm treat these:

1
// src/index.ts — runtime code can import a `dependency`
2
import { nanoid } from "nanoid";
3

4
export function makeId(prefix: string): string {
5
  return `${prefix}-${nanoid(6)}`;
6
}

1
// test/id.test.ts — test code reaches for devDependencies
2
import { test, expect } from "vitest";
3
import * as fc from "fast-check";
4
import { makeId } from "../src/index.js";
5

6
test("ids start with the prefix", () => {
7
  fc.assert(fc.property(fc.string(), (p) => makeId(p).startsWith(p)));
8
});

Three things to notice, because Rust will mirror two of them and tighten the third:

npm install --production (or npm ci --omit=dev) skips devDependencies, but nothing stops your src/index.ts from importing vitest — the boundary is a convention enforced only by what you choose to import.
optionalDependencies may fail to install without failing the whole install (e.g. fsevents is macOS-only).
There is no separate bucket for “code that runs during the build” — bundler plugins just live in devDependencies.

Rust Equivalent

The same project as a Rust crate. Each kind of dependency lives in its own table, and Cargo enforces the boundaries:

1
[package]
2
name = "idgen"
3
version = "0.1.0"
4
edition = "2024"
5

6
# Ships to production. Available to src/ and everything else.
7
[dependencies]
8
serde_json = { version = "1", optional = true }   # only compiled when a feature turns it on
9

10
# Compiled ONLY for `cargo test`/`cargo bench`/`cargo run --example`.
11
# Never compiled into your library or binary, never seen by downstream crates.
12
[dev-dependencies]
13
proptest = "1.11.0"
14
criterion = "0.8.2"
15

16
# Compiled and run on the BUILD machine, for build.rs only. Not linked into your program.
17
[build-dependencies]
18
chrono = "0.4"
19

20
[features]
21
# Turn the optional dependency on with `--features json`.
22
json = ["dep:serde_json"]

The library and its property test, where the dev-dependency is only reachable from the tests/ directory:

1
// src/lib.rs — only `[dependencies]` are in scope here
2
/// Generate a zero-padded id, e.g. `"user-000042"`.
3
pub fn make_id(prefix: &str, n: u64) -> String {
4
    format!("{prefix}-{n:06}")
5
}

1
// tests/properties.rs — an integration test; `[dev-dependencies]` ARE in scope here
2
use idgen::make_id;
3
use proptest::prelude::*;
4

5
proptest! {
6
    #[test]
7
    fn id_always_starts_with_prefix(prefix in "[a-z]{1,8}", n in 0u64..1_000_000) {
8
        let id = make_id(&prefix, n);
9
        prop_assert!(id.starts_with(&prefix));
10
        prop_assert!(id.contains('-'));
11
    }
12
}

Running the suite compiles proptest only now, not during a normal build:

1
     Running tests/properties.rs (target/debug/deps/properties-8252496bc40fbcfe)
2

3
running 1 test
4
test id_always_starts_with_prefix ... ok
5

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

Note: Add dependencies to the right table without hand-editing TOML: cargo add proptest --dev, cargo add cc --build, and cargo add serde_json --optional. The --dev, --build, and --optional flags have been built into cargo add since Cargo 1.62 — no cargo-edit install needed. See cargo-commands.md and dependencies.md.

Detailed Explanation

`[dev-dependencies]`: the direct analog of `devDependencies`

A dev-dependency is compiled only when Cargo builds your tests, benchmarks, examples, or doc-tests. It is not compiled when someone runs cargo build, cargo build --release, or depends on your crate from their own project.

The crucial difference from npm is scope enforcement, not just installation. In Node, import "vitest" from src/ works fine on your machine (it only breaks in production where dev-deps weren’t installed). In Rust, a dev-dependency simply does not exist as far as src/ is concerned — referencing it from library or binary code is a compile error, caught immediately on your own machine. We hit that error on purpose in Common Pitfalls.

Where dev-dependencies are in scope:

Location	Purpose	Dev-deps in scope?
`src/lib.rs`, `src/main.rs`	Your shipped code	No
`tests/*.rs`	Integration tests	Yes
`benches/*.rs`	Benchmarks	Yes
`examples/*.rs`	Runnable examples	Yes
`#[cfg(test)] mod tests` inside `src/`	Unit tests	Yes (only under `cfg(test)`)
Doc-tests in `///` comments	Documentation examples	Yes

Tip: A unit test module guarded by #[cfg(test)] inside src/lib.rs can use dev-dependencies, because that module is compiled only in the test build. But the surrounding non-test code in the same file still cannot. The #[cfg(test)] attribute is the switch. See ../13-testing/README.md for the full testing story.

The payoff is visible in what ships. A normal release build compiles only your crate — no criterion, no proptest:

1
$ cargo build --release
2
   Compiling idgen v0.1.0 (/private/tmp/idgen_probe/idgen)
3
    Finished `release` profile [optimized] target(s) in 0.22s

And a downstream consumer’s dependency graph (cargo tree -e no-dev, the edges they actually pull) contains none of your dev-dependencies:

1
$ cargo tree -e no-dev
2
idgen v0.1.0 (/private/tmp/idgen_probe/idgen)

Benchmarks: the most common reason to reach for a dev-dependency

criterion is the de-facto statistical benchmarking crate, and it is always a dev-dependency. A benchmark lives in benches/ and is declared in the manifest with harness = false so Cargo hands control to Criterion’s runner instead of the built-in test harness:

1
[[bench]]
2
name = "id_bench"
3
harness = false

1
use criterion::{criterion_group, criterion_main, Criterion};
2
use idgen::{checksum, make_id};
3
use std::hint::black_box;
4

5
fn bench_make_id(c: &mut Criterion) {
6
    c.bench_function("make_id", |b| {
7
        b.iter(|| make_id(black_box("user"), black_box(42)))
8
    });
9
}
10

11
criterion_group!(benches, bench_make_id);
12
criterion_main!(benches);

cargo bench compiles Criterion (a dev-dependency) and runs the measurement:

1
make_id                 time:   [73.714 ns 76.545 ns 81.134 ns]
2
Found 11 outliers among 100 measurements (11.00%)
3
  5 (5.00%) high mild
4
  6 (6.00%) high severe

Note: std::hint::black_box (stabilized in Rust 1.66) stops the optimizer from deleting code whose result you ignore — the Rust equivalent of the tricks JS micro-benchmark libraries use to defeat dead-code elimination.

`[build-dependencies]`: a bucket npm doesn’t have

There is no package.json equivalent of [build-dependencies]. These are crates used by build.rs, a build script that compiles and runs on the build machine before your crate compiles. Build-dependencies are linked into the build script, never into your program, and — like dev-dependencies — are invisible to src/.

A common, dependency-light use is code generation: the build script writes a .rs file into the OUT_DIR Cargo provides, and src/ pulls it in with include!.

1
// build.rs — runs at build time; `[build-dependencies]` are in scope here
2
use std::{env, fs, path::Path};
3

4
fn main() {
5
    // `chrono` is a BUILD-dependency: usable here, NOT in src/.
6
    let now = chrono::Utc::now().format("%Y-%m-%d").to_string();
7
    let out_dir = env::var("OUT_DIR").unwrap();
8
    let dest = Path::new(&out_dir).join("build_info.rs");
9
    fs::write(&dest, format!("pub const BUILD_DATE: &str = \"{now}\";\n")).unwrap();
10

11
    // Re-run this script only when build.rs itself changes (not on every build).
12
    println!("cargo:rerun-if-changed=build.rs");
13
}

1
// src/main.rs — splices in the file build.rs generated
2
include!(concat!(env!("OUT_DIR"), "/build_info.rs"));
3

4
fn main() {
5
    println!("greeter built on {BUILD_DATE}");
6
}

1
$ cargo run
2
   Compiling greeter v0.1.0 (/private/tmp/build_probe/greeter)
3
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 3.25s
4
     Running `target/debug/greeter`
5
greeter built on 2026-05-31

This page stays in the manifest lane: what [build-dependencies] is and when it compiles. For the build-script API itself — cargo::rerun-if-changed, linking native C libraries, more code-generation patterns — see build-scripts.md.

Optional dependencies: `dependencies` that only appear behind a feature

Marking a dependency optional = true means it is not compiled by default; a feature must request it. This is how crates offer “pay for what you use” integrations (a serde impl, a tokio runtime, JSON support) without forcing every user to compile them.

1
[dependencies]
2
serde_json = { version = "1", optional = true }
3

4
[features]
5
# `dep:serde_json` activates the optional dependency without leaking its name as a feature.
6
json = ["dep:serde_json"]

1
fn plain_report(name: &str, count: u64) -> String {
2
    format!("{name}: {count}")
3
}
4

5
// Compiled only when the `json` feature (and thus serde_json) is enabled.
6
#[cfg(feature = "json")]
7
fn json_report(name: &str, count: u64) -> String {
8
    serde_json::json!({ "name": name, "count": count }).to_string()
9
}
10

11
fn main() {
12
    println!("{}", plain_report("requests", 7));
13

14
    #[cfg(feature = "json")]
15
    println!("{}", json_report("requests", 7));
16

17
    #[cfg(not(feature = "json"))]
18
    println!("(build with --features json for JSON output)");
19
}

The default build never touches serde_json; opting in pulls it in and compiles the gated code:

1
$ cargo run
2
requests: 7
3
(build with --features json for JSON output)
4

5
$ cargo run --features json
6
requests: 7
7
{"count":7,"name":"requests"}

This is a genuinely sharper tool than npm’s optionalDependencies, which is about install failures being non-fatal (platform-specific native modules). Rust’s optional is about compile-time presence controlled by features — a different mechanism for a different goal. There is no optionalDependencies-style “try to install, shrug if it fails” in Cargo, because Cargo resolves a complete, reproducible graph up front (see Cargo.lock in cargo.md).

Key Differences

Concept	TypeScript / npm	Rust / Cargo
Runtime deps	`dependencies`	`[dependencies]`
Test/tooling deps	`devDependencies`	`[dev-dependencies]`
Build-time-only deps	(none — live in `devDependencies`)	`[build-dependencies]` (for `build.rs`)
Conditional/optional deps	`optionalDependencies` (install may fail silently)	`optional = true` + a feature (compile-time gate)
Boundary enforcement	Convention; `src/` can import a devDependency	Compiler error if `src/` uses a dev/build dependency
Omitting dev deps	`npm ci --omit=dev`	Automatic — `cargo build` never compiles them
What downstream users get	Your `dependencies` (transitively)	Your `[dependencies]` only; dev/build deps never propagate

Three mental-model shifts for a TypeScript developer:

The buckets are enforced by the compiler, not by which files you happen to import. You cannot “accidentally ship a test dependency” by importing it from production code — it won’t compile.
[build-dependencies] is a third, distinct kind. Build-time tooling that runs (code generators, native-lib probing) is separated from test tooling. In npm both would be devDependencies.
Optional means “feature-gated at compile time,” not “best-effort install.” It is the dependency arm of the feature system, covered in feature-flags.md.

Note: The same crate can appear in more than one table — e.g. serde as a normal dependency and serde_json as a dev-dependency. Cargo de-duplicates by version in the lockfile, so listing a crate in both [dependencies] and [dev-dependencies] is fine and sometimes necessary (a normal-dep feature you only need in tests).

Common Pitfalls

Pitfall 1: Using a dev-dependency from `src/`

The single most common mistake. You add proptest as a dev-dependency, then reach for it in src/lib.rs:

1
use proptest::prelude::*; // does not compile (error[E0433]): proptest is a dev-dependency
2

3
pub fn make_id(prefix: &str, n: u64) -> String {
4
    format!("{prefix}-{n:06}")
5
}

The real compiler output:

1
error[E0433]: failed to resolve: use of unresolved module or unlinked crate `proptest`
2
 --> src/lib.rs:1:5
3
  |
4
1 | use proptest::prelude::*; // does not compile (error[E0433]): proptest is a dev-dependency
5
  |     ^^^^^^^^ use of unresolved module or unlinked crate `proptest`
6
  |
7
  = help: if you wanted to use a crate named `proptest`, use `cargo add proptest` to add it to your `Cargo.toml`
8

9
error: could not compile `idgen` (lib) due to 1 previous error

Fix: if the crate is genuinely needed by shipping code, move it to [dependencies] (cargo add proptest). If it is only for tests, keep the usage in tests/, benches/, or a #[cfg(test)] module.

Pitfall 2: Using a build-dependency from `src/`

build.rs and src/ have separate dependency graphs. A crate in [build-dependencies] is not available to your program:

1
fn main() {
2
    let now = chrono::Utc::now(); // does not compile (error[E0433]): chrono is a build-dependency
3
    println!("now is {now}");
4
}

1
error[E0433]: failed to resolve: use of unresolved module or unlinked crate `chrono`
2
 --> src/main.rs:4:15
3
  |
4
4 |     let now = chrono::Utc::now(); // does not compile (error[E0433]): chrono is a build-dependency
5
  |               ^^^^^^ use of unresolved module or unlinked crate `chrono`
6
  |
7
  = help: if you wanted to use a crate named `chrono`, use `cargo add chrono` to add it to your `Cargo.toml`

Fix: if build.rs needs it, keep it in [build-dependencies]; if your program needs it at runtime, add it to [dependencies] as well (the build script’s copy and the runtime copy are independent).

Pitfall 3: An optional dependency silently becomes a feature name

If you mark a dependency optional = true but never reference it via dep: in any feature, Cargo creates an implicit feature with the same name as the dependency. That sometimes surprises people:

1
# Cargo.toml — no [features] table at all
2
[dependencies]
3
serde_json = { version = "1", optional = true }

1
$ cargo run                          # default: implicit feature off
2
json feature off
3

4
$ cargo run --features serde_json    # an implicit feature named after the optional dep
5
json feature on: {"ok":true}

This compiles and works, but it leaks the dependency’s name into your public feature surface — a breaking change if you later rename or drop the dep. Best practice: give the dependency a deliberate feature using the dep: prefix (json = ["dep:serde_json"]), which suppresses the implicit feature so only your chosen name is public. The dep: syntax has been available since Cargo 1.60.

Pitfall 4: Expecting `cargo tree` to hide dev-dependencies

Unlike a release build, the default cargo tree view does list your own crate’s dev-dependencies (under a [dev-dependencies] heading) because it shows the whole local graph:

1
$ cargo tree
2
idgen v0.1.0 (/private/tmp/idgen_probe/idgen)
3
[dev-dependencies]
4
├── criterion v0.8.2
5
│   ├── alloca v0.4.0
6
...

That is expected — it does not mean those crates ship. To see exactly what propagates to consumers (the deps that actually build into your artifact), use cargo tree -e no-dev. Don’t conflate “appears in cargo tree” with “compiled into the binary.”

Best Practices

Put benchmarking and property/test crates in [dev-dependencies]. criterion, proptest, mockall, assert_cmd, tempfile-for-tests — all dev-dependencies. They never bloat your release artifact.
Reserve [build-dependencies] for crates build.rs actually calls. If you don’t have a build.rs, you don’t need this table. Keep build scripts (and their dependency trees) small — they sit on every clean build’s critical path.
Make optional dependencies explicit features with dep:. Write json = ["dep:serde_json"] rather than relying on the implicit feature, so your public feature names are intentional. See feature-flags.md for additive feature design.
Use cargo add with the right flag (--dev, --build, --optional) instead of editing TOML by hand — it places the entry in the correct table and resolves the latest compatible version.
Declare benchmarks with harness = false when using Criterion, and keep each bench file focused. Run them with cargo bench, never as part of cargo test.
Don’t fear duplicating a crate across tables. Listing serde in [dependencies] and again (perhaps with extra features) in [dev-dependencies] is idiomatic when tests need capabilities production doesn’t.

Real-World Example

A small library crate that exposes an optional JSON-export feature, is property-tested, and is benchmarked — using all three dependency tables at once.

1
[package]
2
name = "idgen"
3
version = "0.1.0"
4
edition = "2024"
5

6
[dependencies]
7
serde_json = { version = "1", optional = true }
8

9
[dev-dependencies]
10
proptest = "1.11.0"
11
criterion = "0.8.2"
12

13
[features]
14
json = ["dep:serde_json"]
15

16
[[bench]]
17
name = "id_bench"
18
harness = false

1
// src/lib.rs — production code: only [dependencies] (and feature-gated optional ones)
2
/// Generate a zero-padded id, e.g. `"user-000042"`.
3
pub fn make_id(prefix: &str, n: u64) -> String {
4
    format!("{prefix}-{n:06}")
5
}
6

7
/// Sum the numeric suffixes of a slice of ids.
8
pub fn checksum(ids: &[String]) -> u64 {
9
    ids.iter()
10
        .filter_map(|s| s.rsplit('-').next())
11
        .filter_map(|num| num.parse::<u64>().ok())
12
        .sum()
13
}
14

15
/// JSON export — compiled only with `--features json`.
16
#[cfg(feature = "json")]
17
pub fn ids_to_json(ids: &[String]) -> String {
18
    serde_json::to_string(ids).expect("ids serialize")
19
}

1
// benches/id_bench.rs — uses the criterion dev-dependency
2
use criterion::{criterion_group, criterion_main, Criterion};
3
use idgen::{checksum, make_id};
4
use std::hint::black_box;
5

6
fn bench_checksum(c: &mut Criterion) {
7
    let ids: Vec<String> = (0..1000).map(|n| make_id("u", n)).collect();
8
    c.bench_function("checksum_1000", |b| b.iter(|| checksum(black_box(&ids))));
9
}
10

11
criterion_group!(benches, bench_checksum);
12
criterion_main!(benches);

1
// tests/properties.rs — uses the proptest dev-dependency
2
use idgen::make_id;
3
use proptest::prelude::*;
4

5
proptest! {
6
    #[test]
7
    fn checksum_components_are_numeric(prefix in "[a-z]{1,8}", n in 0u64..1_000_000) {
8
        let id = make_id(&prefix, n);
9
        let suffix = id.rsplit('-').next().unwrap();
10
        prop_assert!(suffix.parse::<u64>().is_ok());
11
    }
12
}

Each command compiles only the relevant tables:

1
$ cargo build                 # [dependencies] only; serde_json off, no criterion/proptest
2
$ cargo test                  # + [dev-dependencies]; runs the proptest integration test
3
$ cargo bench                 # + criterion; runs benchmarks
4
$ cargo build --features json # pulls in the optional serde_json

Verified benchmark output for checksum_1000:

1
checksum_1000           time:   [15.281 µs 17.581 µs 20.611 µs]
2
Found 18 outliers among 100 measurements (18.00%)
3
  6 (6.00%) high mild
4
  12 (12.00%) high severe

The release artifact a consumer receives contains only idgen (plus serde_json if they enable json) — never proptest or criterion.

Exercises

Exercise 1: Sort a crate into the right table

Difficulty: Beginner

Objective: Build the correct mental model for which dependency goes where.

Instructions: You are writing a library crate that (a) parses JSON config at runtime, (b) generates a Rust constants file from a .txt data file during the build, and (c) is fuzz-tested. For each of serde_json, a hypothetical txt-to-rs code generator used by build.rs, and proptest, write the cargo add command that places it in the correct table. Then state which table each lands in.

Solution

1
cargo add serde_json        # runtime parsing -> [dependencies]
2
cargo add txt-to-rs --build # used by build.rs -> [build-dependencies]
3
cargo add proptest --dev    # testing only    -> [dev-dependencies]

Resulting manifest tables:

1
[dependencies]
2
serde_json = "1"
3

4
[build-dependencies]
5
txt-to-rs = "..."   # only build.rs may use this
6

7
[dev-dependencies]
8
proptest = "1.11.0" # only tests/benches/examples may use this

serde_json ships and is reachable from src/. txt-to-rs runs on the build machine and is reachable only from build.rs. proptest is compiled only for cargo test/cargo bench and is reachable only from test code.

Exercise 2: Add a property test that uses a dev-dependency

Difficulty: Intermediate

Objective: Wire up a dev-dependency and prove it is not visible to src/.

Instructions: Start from a library with pub fn double(n: u32) -> u32 { n * 2 } in src/lib.rs. Add proptest as a dev-dependency and write an integration test in tests/ asserting that double(n) is always even for n in 0..1000. Then try adding use proptest::prelude::*; to the top of src/lib.rs and run cargo build — explain the error.

Solution

1
cargo add proptest --dev

1
pub fn double(n: u32) -> u32 {
2
    n * 2
3
}

1
use mylib::double; // replace `mylib` with your crate name
2
use proptest::prelude::*;
3

4
proptest! {
5
    #[test]
6
    fn double_is_even(n in 0u32..1000) {
7
        prop_assert_eq!(double(n) % 2, 0);
8
    }
9
}

cargo test compiles proptest and passes. But adding use proptest::prelude::*; to src/lib.rs fails to build with:

1
error[E0433]: failed to resolve: use of unresolved module or unlinked crate `proptest`

because src/ only sees [dependencies], never [dev-dependencies]. The boundary is enforced by the compiler, not by convention — that is the central difference from npm’s devDependencies.

Exercise 3: Gate an optional dependency behind a feature

Difficulty: Advanced

Objective: Turn a normal dependency into an opt-in one and verify both build paths, avoiding the implicit-feature pitfall.

Instructions: Take a binary crate that prints a report. Make serde_json an optional dependency, expose a json feature using the dep: syntax, and add a json_report function compiled only under that feature. Verify cargo run (no JSON) and cargo run --features json (JSON) both work. Explain why json = ["dep:serde_json"] is preferable to leaving the feature implicit.

Solution

1
[dependencies]
2
serde_json = { version = "1", optional = true }
3

4
[features]
5
json = ["dep:serde_json"]

1
fn plain_report(name: &str, count: u64) -> String {
2
    format!("{name}: {count}")
3
}
4

5
#[cfg(feature = "json")]
6
fn json_report(name: &str, count: u64) -> String {
7
    serde_json::json!({ "name": name, "count": count }).to_string()
8
}
9

10
fn main() {
11
    println!("{}", plain_report("requests", 7));
12

13
    #[cfg(feature = "json")]
14
    println!("{}", json_report("requests", 7));
15

16
    #[cfg(not(feature = "json"))]
17
    println!("(build with --features json for JSON output)");
18
}

Verified output:

1
$ cargo run
2
requests: 7
3
(build with --features json for JSON output)
4

5
$ cargo run --features json
6
requests: 7
7
{"count":7,"name":"requests"}

Using dep:serde_json is preferable because it suppresses the implicit feature that Cargo would otherwise create from the optional dependency’s name. Without it, both --features json and --features serde_json would work, leaking the dependency’s name into your public feature surface — a future breaking change if you rename or drop the dependency. The dep: prefix keeps json as the only public knob.

Dev-Dependencies, Build-Dependencies, and Optional Dependencies

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

[dev-dependencies]: the direct analog of devDependencies

Benchmarks: the most common reason to reach for a dev-dependency

[build-dependencies]: a bucket npm doesn’t have

Optional dependencies: dependencies that only appear behind a feature

Key Differences

Common Pitfalls

Pitfall 1: Using a dev-dependency from src/

Pitfall 2: Using a build-dependency from src/

Pitfall 3: An optional dependency silently becomes a feature name

Pitfall 4: Expecting cargo tree to hide dev-dependencies

Best Practices

Real-World Example

Further Reading

Exercises

Exercise 1: Sort a crate into the right table

Exercise 2: Add a property test that uses a dev-dependency

Exercise 3: Gate an optional dependency behind a feature

`[dev-dependencies]`: the direct analog of `devDependencies`

`[build-dependencies]`: a bucket npm doesn’t have

Optional dependencies: `dependencies` that only appear behind a feature

Pitfall 1: Using a dev-dependency from `src/`

Pitfall 2: Using a build-dependency from `src/`

Pitfall 4: Expecting `cargo tree` to hide dev-dependencies