rust-workspace

Rust ワークスペースとプロジェクトの構成

根拠：Cargo Book — Workspaces、The Book ch7 および ch14-03、Rust Reference ch7、RFC 1525、matklad — Large Rust Workspaces。

このスキルでは、プロジェクトにいくつのクレートを用意し、それらをどう関連付けるかを判断します。関連スキルの rust-module-layout では、1 つのクレートの src/ 内に何を配置するかを扱います。

対応範囲

✅ 得意分野

1. 単一クレートにするか、複数クレートのワークスペースにするかの判断（具体的な 5 つのトリガーを含む判断ツリー）
2. プロジェクトに応じたワークスペース構成：小規模なルート直下型、ハイブリッド／ドメイン別グループ型、crates/ 集約型、ネスト型、ルートパッケージ型
3. 仮想マニフェストとルートパッケージの比較、および移行
4. ワークスペースレベルの共有設定：[workspace.package]、[workspace.dependencies]、[workspace.lints]
5. 依存関係の DAG（型 → コア → SDK → サーバー → バイナリ）
6. 「ルートパッケージ混在」アンチパターンの診断とリファクタリング
7. クレートの命名、公開、メンバー間のバージョン調整

⚠️ 前提条件

1. Rust の所有権と基本的なモジュール構文 — rust-stable を参照
2. クレート内のモジュール構成（lib.rs ファサード、mod 宣言、可視性）— rust-module-layout を参照

❌ 対象外

1. Cargo.toml の [dependencies] 構文と機能解決 → rust-cargo-build を使用
2. クレート内の src/ ディレクトリ構成 → rust-module-layout を使用
3. Rust 構文の基礎 → rust-stable を使用
4. テストの構成 → rust-testing を使用

使用する場面

• 「これをワークスペースに分割すべきですか、それとも 1 つのクレートのままにすべきですか？」
• 「Cargo ワークスペースを設定するにはどうすればよいですか？」
• 「rbatis スタイルのルートパッケージ混在をリファクタリングしてください」
• 「cargo はなぜルートのクレートを 1 つしかビルドしないのですか？」
• 「ワークスペースのメンバー間で依存関係を共有するにはどうすればよいですか？」
• 「依存関係の方向は適切ですか？」

データプライバシー

このスキルは、ユーザーデータを収集、保存、送信しません。

---

基礎 — パッケージ、クレート、モジュール

クレート内のモジュール構成の詳細（mod ファイル、可視性、再エクスポート）は、関連スキルの rust-module-layout で扱います。このセクションでは、プロジェクトレベルの判断に関わる部分のみを扱います。

パッケージ、クレート、ワークスペースの違い

用語	意味
パッケージ	1 つの Cargo.toml と、それが参照するソース。crates.io に公開する単位です
クレート	コンパイル単位です。ライブラリ（src/lib.rs）またはバイナリ（src/main.rs、src/bin/*.rs）のいずれかです。1 つのパッケージに複数のクレート（ライブラリ 1 つとバイナリ N 個）を含めることができます。
ワークスペース	1 つの Cargo.lock と target/ を共有するパッケージの集合です。
モジュール	クレート内で名前を付けられるスコープです。mod foo; で宣言し、src/foo.rs または src/foo/mod.rs に解決されます。

単一パッケージの構成

# Library only                      # Binary only                  # Library + binary
my-lib/                             my-app/                        my-crate/
├── Cargo.toml                      ├── Cargo.toml                 ├── Cargo.toml
└── src/                            └── src/                       └── src/
    └── lib.rs                          └── main.rs                 ├── lib.rs
                                                                      └── main.rs

# Multi-binary (one package, multiple binaries)
my-app/
├── Cargo.toml
└── src/
    ├── lib.rs
    ├── main.rs                      # binary named after the package
    └── bin/
        ├── tool_a.rs                # binary `tool_a`
        └── tool_b.rs                # binary `tool_b`

モジュール宣言（Java／Python 開発者が意外に感じるルール）

// src/lib.rs — declare modules explicitly; directories are NOT auto-discovered
pub mod front_of_house;      // loads src/front_of_house.rs OR src/front_of_house/mod.rs
mod back_of_house;           // private
pub(crate) mod utils;        // crate-visible

すべてがデフォルトで非公開であり、pub によって公開されます。可視性モデル全体、親境界に基づく到達可能性のルール、最新の foo.rs + foo/ 構成については、rust-module-layout を参照してください。

use パス（クイックリファレンス）

use crate::front_of_house::hosting;       // absolute (current crate)
use std::collections::HashMap;            // absolute (external)
use self::back_of_house::Cook;            // relative (current module)
use super::parent_module::helper;         // relative (parent)
use std::{cmp::Ordering, io};             // nested
use std::fmt::Result as FmtResult;        // alias
pub use crate::front_of_house::hosting;   // re-export (facade pattern)

条件付きコンパイル

#[cfg(target_os = "linux")]
fn only_linux() {}

#[cfg(feature = "serde")]
fn with_serde() {}

#[cfg_attr(feature = "serde", derive(Serialize, Deserialize))]
struct Config;

if cfg!(target_os = "linux") { /* runtime check */ }

プロジェクトのスキャフォールディング

cargo new my-app              # Binary project
cargo new my-lib --lib        # Library project
cargo init                    # Initialize current directory

複数クレートのワークスペースでは、ルートの仮想マニフェストを手動で作成します（cargo workspace new はありません）。以下の判断モデルに基づいてメンバーの構成を選び、その後 cargo new --lib <selected-member-path> を実行します。小規模なルート直下型ワークスペースなら cargo new --lib my-core、大規模な crates/ 集約型ワークスペースなら cargo new --lib crates/my-core を使う場合があります。テンプレートには cargo-generate を使用してください。

---

ワークスペースのパターン（単一クレートと複数クレート）

権威ある情報源：Cargo Book — Workspaces、The Book ch14-03、matklad — Large Rust Workspaces、RFC 1525。

ワークスペースとは、単一の Cargo.lock と target/ ディレクトリを共有する、1つ以上のパッケージの集合です。ワークスペースが存在する理由は4つあります。ビルドの高速化（依存関係のコンパイルを共有）、バージョンの調整（1つのロックファイルと1つの cargo publish のフロー）、境界の明確化（各クレートが独自の公開 API を持つ独立したコンパイル単位）、個別の再利用（ユーザーが他のクレートを引き込まずに1つのクレートに依存可能）です。

判断フロー — クレートはいくつ必要か？

Is this project one cohesive library or one binary?
├── Yes → Single-crate layout (Section 8.1)
└── No, it has multiple subdomains
    ├── Do the subdomains share types and call each other heavily?
    │   └── Single-crate with module directories (use rust-module-layout skill)
    └── At least one subdomain is independently useful / independently versioned / has different deps?
        └── Multi-crate workspace (Section 8.2)

経験則：次のいずれかに当てはまる場合にのみ、クレートを分割してください（references/production-workspace-boundaries.md を参照）。

1. サブドメインに独立した公開、またはサードパーティによる再利用が必要である
2. サブドメインに個別の feature／ターゲット／no_std／WASM の境界が必要である
3. コンパイル時に逆方向の依存を禁止する必要がある（例：core が tokio に依存してはならない）
4. サブドメインが独自にバージョン管理される公開 API を持つ
5. テスト／ビルドのライフサイクルが大きく異なる

どれにも当てはまらない場合は、クレートよりモジュールを優先してください。モジュールのほうが手軽です（公開やバージョン調整、個別の Cargo.toml が不要です）。クレート内の構成については rust-module-layout スキルを参照してください。

単一クレートのレイアウト

小規模から中規模のプロジェクトでは、これがデフォルトです。Cargo.toml が1つ、src/ が1つあります。バリエーションは4つです。ライブラリのみ、バイナリのみ、ライブラリとバイナリ（同じパッケージ）、または複数バイナリ（src/bin/<name>.rs）です。4つすべての基本構成については examples/single-crate.md を参照してください。

ワークスペースへ移行するタイミング：バイナリまたはライブラリに、独立した依存関係／機能／ターゲットの境界、リリース方針、またはビルド／テストのライフサイクルが必要になったときです。2つ目のバイナリだけであれば、同じパッケージ内の src/bin/ に置いたままにできます。

複数クレートのワークスペース — ルートの2つの形式

Cargo は、ルートの Cargo.toml に2つの形式をサポートしています。

形式	ルートに含まれるもの	使用する場面
仮想マニフェスト	[workspace] のみ — [package] なし	新しいワークスペースではデフォルトです。 ルートがすっきりし、最上位に src/ がありません。メンバーはルート直下、ハイブリッド、または包含型のいずれにもできます。
ルートパッケージ	[workspace] と [package]、およびルートの src/	あるパッケージが明確に主役となる小規模（2～3パッケージ）のワークスペースで、以下のトレードオフを受け入れられる場合に使用します。

Cargo チームとコミュニティ（特に matklad の Large Rust Workspaces）は、重要なワークスペースでは仮想マニフェストを推奨しています。

1. ルートの散乱 — ルートに [package] があると、他のすべてのクレートのディレクトリと並んで、src/、tests/、benches/ が最上位に置かれます。
2. コマンドの使いやすさ — ルートパッケージがある場合、ルートで cargo build を実行すると、ルートパッケージのみがビルドされます。すべてをビルドするには --workspace が必要です。仮想マニフェストでは、デフォルトですべてのメンバーがビルドされます。
3. 公開時の煩雑さ — ルートパッケージとメンバーがあると、cargo publish の順序が分かりにくくなります。

プロジェクト主導のレイアウトパターン

パターン	レイアウト	適用場面	使用例
A. ルート直下のフラット構成（仮想マニフェスト）	ルートの Cargo.toml と並ぶ <member>/	小規模で一貫性のあるワークスペースのデフォルト。通常、パッケージ／メンバーが2〜8個	Tokio、Serde、Clap
B. ハイブリッド／ドメイン別グループ構成	ルート直下のコアメンバーに加え、support/*、examples/*、または別の実際のグループ	安定したグループがある、またはアダプター／サンプルが多くなった成長中のワークスペース	フレームワークや移行用のワークスペース
C. 内包／グループ構成	crates/<member>/ または crates/<category>/*	大規模なワークスペース、多言語リポジトリ、または Rust 用のコンテナが必要なルート	Bevyのような大規模リポジトリ
D. ネストしたサブワークスペース	独自の [workspace] を持つ vendor/<sub>/	Git サブモジュールやベンダー提供ワークスペースの分離（まれ）	ベンダー提供の上流ワークスペース
E. ルートパッケージ	ルートの [package] と、兄弟または内包されたメンバー	主要なクレートが明確に1つある、パッケージが2〜3個の場合	ライブラリと付属の CLI

ワークスペースのメンバー数は判断材料であり、絶対的なルールではありません。まずパッケージ／クレートの境界を決めてから、リポジトリルートの煩雑さ、独立した公開の必要性、アダプター／プラグインのグループ、ターゲット、サンプル／テスト、他の言語、定着しているパスを検討してください。レビュー時の目安として、一貫性のあるパッケージが2〜8個なら通常はルート直下のフラット構成を維持します。8〜20個程度なら、ルート直下のフラット構成とハイブリッド構成を比較します。20個以上なら、グループ化または crates/ の利用が一般的に有効です。Rust の境界を設ける理由なしに、Maven／Gradle のモジュールごとに Cargo パッケージを作成してはいけません。

完全なスケルトンと判断マトリクスについては、references/workspace-layouts.md を参照してください。

パターンAのスケルトン — 小規模ワークスペースのデフォルト

my-project/
├── Cargo.toml                      # virtual: [workspace]
├── my-core/                        # library
│   ├── Cargo.toml
│   └── src/lib.rs
├── my-net/                         # library
│   └── ...
└── my-cli/                         # binary
    └── src/main.rs

# root Cargo.toml — virtual manifest
[workspace]
resolver = "3"
members = ["my-core", "my-net", "my-cli"]

[workspace.package]
edition = "2024"
version = "0.1.0"
license = "Apache-2.0"

[workspace.dependencies]
serde = { version = "1", features = ["derive"] }   # pin once
my-core = { path = "my-core" }                      # internal deps here

# my-net/Cargo.toml
[package]
name = "my-net"
version.workspace = true               # inherits from [workspace.package]
edition.workspace = true

[dependencies]
serde.workspace = true                 # inherits from [workspace.dependencies]
my-core.workspace = true               # internal workspace dep

「ルートパッケージ混在」のアンチパターン

Java/Maven や Python から移ってきた開発者によくある間違いは、実質的なコードを含む [package] をワークスペースのルートに置き、同時にメンバークレートも配置することです。

# Cargo.toml — DON'T (anonymized from a real public crate)
[workspace]
members = ["codegen", "macro-driver", "example"]

[package]                            # ❌ root package + workspace together
name = "my_framework"
version = "4.9.6"

[dependencies]
my-codegen = { path = "codegen" }
my-macro-driver = { path = "macro-driver" }

my-framework/
├── Cargo.toml                       # 163 lines mixing workspace + package config
├── src/                             # ❌ the root package's source pollutes the root
│   ├── lib.rs                       # 30 lines of `pub use *::*`
│   ├── crud.rs                      # 591 lines (monster file — see rust-module-layout)
│   ├── executor.rs                  # 642 lines
│   └── plugin/
├── codegen/                         # member crate
├── macro-driver/                    # member crate
└── tests/

5つの問題点：ルートの汚染、非対称なコマンド（cargo build はルートだけをビルドする）、バージョン管理の結合、明確なファサードがない（lib.rs が一括再エクスポートの集約先になる）、公開後の移行が破壊的変更になること。

リファクタリングの目標 — すべてのクレートを crates/ の下に置く仮想マニフェスト：

my-framework/
├── Cargo.toml                       # virtual manifest — workspace config only
└── crates/
    ├── my-framework/                # was: src/ at root
    │   ├── Cargo.toml
    │   └── src/
    ├── codegen/
    ├── macro-driver/
    └── example/

移行は機械的に行え、公開済みのクレート名も維持されます。6段階の手順全体は references/mixed-root-package-antipattern.md に、実例は examples/migration-mixed-to-virtual.md にあります。

ワークスペースレベルの共有設定

ワークスペースレベルの3つのテーブルにより、メンバー間の設定のずれを解消できます。構文の詳細については、references/workspace-dependencies.md を参照してください。

# root Cargo.toml
[workspace.package]                  # shared package metadata
version = "0.1.0"
edition = "2024"
rust-version = "1.85"
license = "Apache-2.0"

[workspace.dependencies]             # shared external + internal deps
serde = { version = "1", features = ["derive"] }
tokio = { version = "1", features = ["rt-multi-thread", "macros"] }
my-core = { path = "crates/core" }

[workspace.lints.rust]               # shared lint config
unsafe_code = "forbid"
missing_docs = "warn"

メンバー側では .workspace = true を指定して利用します。

# crates/net/Cargo.toml
[package]
name = "my-net"
version.workspace = true             # inherits 0.1.0
edition.workspace = true

[dependencies]
serde.workspace = true               # inherits pinned version + features
my-core.workspace = true

[lints]
workspace = true                     # inherits shared lints

依存関係の方向（DAG）

クレート間の依存関係は有向非巡回グラフを形成します。循環は許可されません（cargo がエラーを出します）。依存関係の方向は意図的に設計してください。

low-level types ──► domain logic ──► application ──► binary
   (my-types)         (my-core)         (my-server)     (my-cli)

アンチパターン — 方向の漏れ：

# crates/core/Cargo.toml — ❌ core depending on CLI concerns
[dependencies]
clap = "4"                           # CLI lib has no business in core
my-cli = { path = "../cli" }         # core cannot depend on the binary

検証：

cargo tree                                    # visualize the dep graph
cargo tree --invert --package my-core         # what depends on my-core?

my-types が std 以外の何かに依存している場合、依存関係の方向が誤っています。レイヤリングのルールについては、references/dependency-direction.md を参照してください。

参考例 — sa-token-rs（11クレートの仮想ワークスペース）

sa-token-rs は、Java の Sa-Token 権限フレームワークを実用的に Rust へ移植したもので、このスキルで解説するパターンのすべてを示す模範例です。仮想マニフェスト、11個のクレート、整理された5層の DAG、crates/<category>/ によるグループ化、完全な [workspace.*] の継承を備えています。

レイアウト（内包構成とドメイン別グループ構成のハイブリッド）

sa-token-rs/
├── Cargo.toml                          # virtual manifest
└── crates/
    ├── sa-token/                       # Layer 3: facade (public API)
    ├── sa-token-core/                  # Layer 1: core types & traits (no internal deps)
    ├── sa-token-derive/                # Layer 2: proc-macro (core only)
    ├── sa-token-context-mock/          # Layer 2: mock context (core only)
    ├── sa-token-dao-memory/            # Layer 2: memory DAO (core only)
    ├── sa-token-dao-redis/             # Layer 4: redis DAO (facade + core)
    ├── sa-token-axum/                  # Layer 4: axum adapter (facade + core)
    ├── sa-token-plugin/                # domain grouping inside container
    │   ├── sa-token-jwt/               # Layer 4: JWT plugin
    │   └── sa-token-sign/              # Layer 4: signature plugin
    ├── sa-token-demo/                  # domain grouping inside container
    │   └── sa-token-demo-axum/         # Layer 5: binary example
    └── sa-token-test/                  # Layer 5: integration tests

DAG — 5層、すべての矢印が上向き

L1  sa-token-core
      ▲
L2  sa-token-derive   sa-token-context-mock   sa-token-dao-memory
      ▲                      ▲                       ▲
L3  sa-token  (facade — aggregates L2 leaves into one public API)
      ▲
L4  sa-token-dao-redis   sa-token-axum   sa-token-jwt   sa-token-sign
      ▲
L5  sa-token-demo-axum   sa-token-test   (binaries + tests)

模デルケースである理由

1. 仮想マニフェスト — ルートに [package] がなく、cargo build でデフォルトですべての11個がビルドされます。
2. コンテインド型とドメイン別グループ化のハイブリッド — リーフには crates/sa-token-* を使用し、プラグインとデモのファミリーは crates/ 以下にグループ化されています。
3. 完全な [workspace.*] 継承 — version、edition = "2024"、rust-version = "1.85"、license、repository、[workspace.lints]（unsafe_code = "forbid"、missing_docs = "warn"、clippy::pedantic = "warn"）、および内部・外部依存関係用の [workspace.dependencies] を備えています。
4. フィーチャーでゲートされたオプション依存関係 — sa-token は redis = ["dep:sa-token-dao-redis"] を公開します。
5. 整理されたDAG — コアには内部依存関係がなく、ファサードが集約し、アダプター／プラグイン／DAOがその上位に位置し、デモ／テストがすべてを利用します。

メンバーごとの完全な Cargo.toml の内訳、DAG の検証コマンド、レイアウトが独立した公開をどのように支援するかについては、references/sa-token-rs-case-study.md を参照してください。

ワークスペースコマンド早見表

cargo build --workspace               # build every member (default in virtual manifest)
cargo build -p my-core                # build one member
cargo test --workspace                # test every member
cargo check --workspace               # fast type-check everything
cargo doc --workspace --no-deps       # docs for every member
cargo publish -p my-core              # publish one member
cargo run -p my-cli                   # run a specific binary

cargo workspaces version minor       # bump all members in lockstep (needs cargo-workspaces)
cargo workspaces publish              # publish all members in topological order

すべてのメンバーに対する一括バージョン更新と公開には、cargo-workspaces をインストールしてください。

---

ワークフロー

1. プロジェクトの種類とクレートの境界を決める — まずは単一クレートから始めます。独立した再利用／バージョン管理、依存関係やターゲットの分離、または異なるライフサイクルのために必要な場合に限り分割します。それ以外の場合はモジュールを使用します。
2. 構成を示す要素を洗い出す — パッケージ数、公開単位、アダプター／プラグインのファミリー、サンプル／テスト、リポジトリルートの煩雑さ、言語、互換性に影響する既存のパスを確認します。
3. レイアウトを選ぶ — 小規模でまとまりのあるワークスペース：ルートフラット型。実際のファミリーを持つ成長中のワークスペース：ハイブリッド／ドメイン別グループ化。大規模または複数言語のワークスペース：コンテインド型／グループ化。数は厳格な基準ではなく、レビューを促す目安として扱います。
4. 共有メタデータと依存関係をワークスペースレベルで固定する — [workspace.package]、[workspace.dependencies]、[workspace.lints] を使用します。メンバー側では .workspace = true を指定してオプトインします。
5. 依存関係の方向を検証する — cargo tree --invert --package my-core を実行し、上位のクレートのみが下位のクレートに依存していることを確認します。逆方向のエッジや循環は避けてください。
6. 命名規則を選ぶ — クレート名には snake_case、Cargo.toml の name にはケバブケースを使用します。単語は省略せず、2文字の略語は避けます（rust-module-layout の命名に関するリファレンスを参照）。
7. 検証する — cargo check --workspace、cargo tree、cargo doc --workspace --no-deps を実行します。生成されたドキュメントのサイドバーを確認し、意図した公開APIの範囲が反映されていることを確かめます。

注意点

1. crate::（現在のクレートルートを参照）と、::other_crate_name::（外部クレートへの絶対パス参照）を区別してください。
2. pub(crate) などの可視性制限は Edition の境界ではありません。Edition 2015 では使えないと決めつけず、プロジェクトの Rust バージョンを確認してください。
3. module.rs と module/mod.rs はどちらもサポートされています。新しいコードでは通常、前者が推奨されますが、mod.rs を使ったときの非推奨警告をエラーと誤解しないでください。
4. ワークスペースのリゾルバー設定はグローバルに適用されます。Edition 2021 ではリゾルバー 2、Edition 2024 ではリゾルバー 3 がデフォルトです。
5. pub(in path) のパス引数は、現在の項目の祖先モジュールを指す必要があり、任意の兄弟モジュール間で可視性を公開するためには使えません。
6. #[path] 属性を使うとファイルシステムの規則が適用されなくなり、適用後はモジュールパスがデフォルトのファイルツリー構造に従わなくなります。
7. 仮想マニフェストには [dependencies] や [package] を含められません。 failed to parse manifest at ... missing field package が表示された場合は、仮想マニフェストとルートパッケージの構文を混在させています。[package] を削除して仮想マニフェストにするか、追加してルートパッケージにしてください。中途半端に両方を使わないでください。
8. ルートパッケージを含むワークスペースのルートで cargo build を実行すると、ルートパッケージだけがビルドされます。 すべてをビルドするには --workspace を使ってください。仮想マニフェストの場合、cargo build ですでにすべてのメンバーがビルドされるため、予期せぬ動作が少なくなります。
9. ワークスペースのグロブが一致するのは1階層だけです。 members = ["crates/*"] は crates/libs/core/ に一致しません。crates/libs/* または明示的なパスを使ってください。ルート直下に配置したメンバーには、明示的な名前か範囲を適切に絞ったグロブを使えますが、パッケージ以外のディレクトリも含まれるため、members = ["*"] は使わないでください。
10. ワークスペース内の path 依存関係にも、公開時にはバージョンが必要です。 my-core = { path = "../core", version = "0.1.0" } のように指定してください。version がないと、cargo publish は拒否します。バージョンを一か所にまとめるには [workspace.dependencies] を使ってください。
11. ワークスペースで共有している依存関係のバージョンを上げるときは、ルートの Cargo.toml だけを編集してください。 メンバークレートでバージョンを再固定すると、共有する目的が失われ、設定に差異が生じます。
12. 公開済みクレートの名前変更は破壊的変更です。 旧名のまま非推奨エイリアスクレート（pub use my_new_name::*;）を1リリースサイクル提供してから削除してください。

オンデマンドリソース

• レイアウト例 — 基本的なモジュールレイアウト
• 概念のクイックリファレンス
• ワークスペースのレイアウト — プロジェクト規模に応じた、ルート直下配置、ハイブリッド、内包型、ネスト型、ルートパッケージのひな形
• 仮想マニフェストとルートマニフェスト — コマンドの使いやすさの比較を含む、詳細な判断ガイド
• ルートパッケージ混在のアンチパターン — rbatis 形式のレイアウトの完全な診断と移行手順
• ワークスペースの依存関係 — [workspace.package] ／ [workspace.dependencies] ／ [workspace.lints] の詳細
• 依存関係の方向 — DAG の規則、レイヤリング、方向が漏れるアンチパターン
• sa-token-rs のケーススタディ — 5層 DAG を持つ実例の11クレート仮想ワークスペース。メンバーごとの詳細、DAG の検証、公開時の影響を解説
• 本番環境向けワークスペース境界：プロトコル、ドメイン、プラットフォーム、トランスポート、SDK、アダプター、バイナリを分割する場合は、該当するセクションをお読みください。
• examples/golden-layout/：単一クレートの CI コンパイル例
• examples/golden-workspace/：3つのクレートからなる、小規模なルート直下配置の仮想ワークスペース例

Official References

• The Book ch 7 — Managing Growing Projects
• The Book ch14-03 — Cargo Workspaces
• Rust Reference ch 7 (Items)
• Rust Reference ch 7.2 (Modules)
• Cargo Book — Workspaces
• Cargo Book — workspace.package
• Cargo Book — Workspace dependencies
• RFC 1525 — Cargo Workspaces
• matklad — Large Rust Workspaces (community best-practice reference)
• Rust API Guidelines — Organization (C-HIERARCHY, C-REEXPORT)