managing-cargo-dependencies

Manage Cargo.toml dependencies across a HASH workspace.

1.6k|123|Updated Jul 15, 2019
One-click install
npx skills add https://github.com/hashintel/hash --skill managing-cargo-dependencies
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: managing-cargo-dependencies
Source: https://github.com/hashintel/hash/tree/main/.claude/skills/managing-cargo-dependencies
Command: npx skills add https://github.com/hashintel/hash --skill managing-cargo-dependencies

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill eliminates the complexity and manual errors associated with managing Rust Cargo.toml dependencies in a monorepo workspace. It ensures consistent, efficient, and bloat-free dependency configurations across your projects, saving you time and reducing build issues.

Core Features & Use Cases

  • Centralized Dependency Management: Guides you to define external crates in the workspace root [workspace.dependencies], enforcing caret versioning and default-features = false for optimal builds.
  • Structured Cargo.toml: Enforces a clear 4-section pattern (Public workspace, Public third-party, Private workspace, Private third-party) within package-level Cargo.toml files for enhanced readability and maintainability.
  • Granular Feature Control: Directs you to enable specific features at the package level, leading to smaller binaries and faster compile times by avoiding unnecessary default features.
  • Use Case: When adding a new external crate like tokio, this skill guides you to add it to the workspace root, disable default features, and then add it to the correct section in your package's Cargo.toml with only the necessary features enabled, ensuring consistency and efficiency.

Quick Start

Use the managing-cargo-dependencies skill to add 'my-new-crate' version '1.2.3' as a private third-party dependency to the 'hash-api' package.

Frequently Asked Questions about managing-cargo-dependencies

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I manage dependencies across a Rust monorepo workspace?

Manage dependencies across a Rust monorepo by defining external crates in the workspace root `[workspace.dependencies]` section with caret versioning and `default-features = false`, then reference them in package-level `Cargo.toml` files organized into four sections: public workspace, public third-party, private workspace, and private third-party dependencies.

What's the best way to organize Cargo.toml files in a multi-package project?

Organize Cargo.toml files using a consistent 4-section pattern within each package: public workspace dependencies, public third-party dependencies, private workspace dependencies, and private third-party dependencies. This structure maintains readability and enforces clear separation between internal and external crates.

How do I reduce build time and binary size when adding Rust crates?

Reduce build time and binary size by disabling unnecessary default features at the workspace root level and enabling only specific required features at the package level. This granular control prevents compiling unused functionality across your workspace.

Can I use workspace = true for all dependencies in a Rust monorepo?

Use `workspace = true` for workspace members defined in the root `[workspace.dependencies]` section to enforce consistent versioning across packages. External crates must be defined in the workspace root with explicit versions and feature flags before referencing them in individual packages.

How do I add a new external crate to a specific package in my workspace?

Add the external crate to the workspace root `[workspace.dependencies]` with caret versioning and `default-features = false`, then reference it in your package's `Cargo.toml` under the appropriate section with only the features your package needs enabled.

What's the difference between public and private dependencies in Cargo.toml?

Public dependencies expose their APIs through your crate's public interface and are visible to downstream consumers, while private dependencies are internal implementation details not exposed in your public API. The 4-section organization keeps this distinction clear and prevents accidental public exposure.