Cargo Workspaces & Publishing

Real Rust projects rarely stay one crate. Workspaces let you manage many related packages together, and crates.io lets you share your work with the world — both powered by Cargo and a few lines of TOML.

Learn Cargo Workspaces & Publishing in our free Rust course — a beginner-friendly interactive lesson with worked examples, a practice exercise and a quick…

Part of the free Rust course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.

In this lesson you'll structure a multi-crate workspace with path dependencies and a shared lockfile, then publish a crate to crates.io with proper metadata, semantic versioning, yanking, and docs.rs.

What You'll Learn in This Lesson

1️⃣ Defining a Workspace

A workspace is a root Cargo.toml with a [workspace] table listing its members . All members share one Cargo.lock and one target/ directory, so versions stay consistent and builds are reused.

Commands like cargo build --workspace and cargo test --workspace then act on every member at once.

2️⃣ Path Dependencies Between Members

Members reference each other with path dependencies : point at the sibling crate's directory and Cargo builds it from local source. This makes cross-crate changes instant — edit the library and the binary sees it immediately.

When you later publish such a crate, you usually give the dependency both a path (used locally) and a version (used by downstream users from crates.io).

3️⃣ Publishing to crates.io

crates.io is Rust's package registry. Publishing needs a unique name , a semver version , plus a description and license . Published versions are permanent; cargo yank only blocks new use.

After a successful cargo publish , docs.rs automatically builds and hosts your crate's documentation — no setup required.

Sketch a workspace with two members and a path dependency, and recall the publish metadata.

📋 Quick Reference — Workspaces & Publishing

Practice quiz

What is a Cargo workspace?

  • A set of packages managed together with a shared output and lockfile
  • A single binary crate
  • A test framework
  • A cloud build server

Answer: A set of packages managed together with a shared output and lockfile. A workspace groups multiple related packages that share one Cargo.lock and one target directory.

Which table in the root Cargo.toml declares a workspace?

A root manifest with a [workspace] table (and its members) defines the workspace.

What do all members of a workspace share?

  • One source file
  • The same crate name
  • A single Cargo.lock and target/ directory
  • Nothing

Answer: A single Cargo.lock and target/ directory. Workspace members share one Cargo.lock and one build output directory for consistency and speed.

How does one workspace member depend on a sibling member?

  • By copying its source
  • With a path dependency like { path = "../other" }
  • Only through crates.io
  • It cannot

Answer: With a path dependency like { path = "../other" }. Local members reference each other with a path dependency pointing at the sibling's directory.

Which command uploads your crate to crates.io?

  • cargo deploy
  • cargo upload
  • cargo release
  • cargo publish

Answer: cargo publish. cargo publish packages and uploads the current crate to the crates.io registry.

Which fields are required in [package] before you can publish?

  • name and version, plus metadata like license/description
  • just authors
  • none
  • only name

Answer: name and version, plus metadata like license/description. crates.io requires name and version, and in practice a description and license (or license-file) too.

Rust crates follow which versioning scheme?

  • Random versioning
  • Semantic versioning (MAJOR.MINOR.PATCH)
  • Alphabetical versioning
  • Calendar versioning

Answer: Semantic versioning (MAJOR.MINOR.PATCH). Cargo expects semantic versioning, where the numbers signal breaking, additive, and fix-level changes.

What does cargo yank do to a published version?

  • Renames the crate
  • Makes it private
  • Deletes it permanently
  • Prevents NEW projects from selecting it while existing users keep working

Answer: Prevents NEW projects from selecting it while existing users keep working. Yanking blocks new dependency resolutions on that version but does not delete it, so existing builds still work.

Where is documentation for published crates automatically built and hosted?

  • readthedocs.io
  • crates.io/docs
  • docs.rs
  • github.io

Answer: docs.rs. docs.rs automatically builds and hosts rustdoc documentation for every crate published to crates.io.

Under semver, a backward-compatible new feature bumps which number?

  • MAJOR
  • MINOR
  • PATCH
  • BUILD

Answer: MINOR. Adding functionality without breaking existing users increments the MINOR version.