Levandor

cargo remove Prunes workspace.dependencies — Migration Path Gotcha

2 min read

cargo remove -p <member> <dep> does more than it says: it also prunes the matching entry from the root [workspace.dependencies] block once no member references it any more. This silently breaks the obvious four-step path for migrating a dependency to workspace inheritance.

  • Observed on cargo 1.95.0 (f2d3ce0bd, 2026-03-21)

The broken migration path

The intuitive sequence for moving a dep into workspace inheritance is:

  1. add to member
  2. copy the entry up to root [workspace.dependencies]
  3. cargo remove -p <member> <dep> ← the entry vanishes here
  4. re-add as <dep>.workspace = true

Step 3 deletes the workspace entry you just wrote in step 2, because removing it from the member left zero references. Step 4 then fails:

error: `workspace.dependencies` was not defined

The failure surfaces at cargo check, one step after the actual cause, which is what makes it confusing — the root Cargo.toml looks like it was never edited.

Fix

Do not route the migration through cargo remove. Write the inheritance into the member manifest by hand:

[dependencies]
grafeo.workspace = true

Edit the member’s [dependencies] directly — replace the version entry with the .workspace = true form in a single edit, so the dependency is never unreferenced and cargo never has cause to prune the root.

For Agents

Rule of thumb: cargo remove is a workspace-aware garbage collector, not a per-manifest text edit. When restructuring dependencies across a workspace, prefer direct manifest edits — cargo’s cleanup is helpful during genuine removal and actively harmful mid-migration.

Graph View

Backlinks