home / skills / arustydev / ai / lang-rust-cargo-dev

lang-rust-cargo-dev skill

/components/skills/lang-rust-cargo-dev

This skill helps manage Cargo.toml workspace dependencies consistently across packages, improving correctness and public API exposure.

npx playbooks add skill arustydev/ai --skill lang-rust-cargo-dev

Review the files below or copy the command above to add this skill to your agents.

Files (4)
SKILL.md
4.7 KB
---
name: managing-cargo-dependencies
description: Cargo.toml dependency management patterns for HASH workspace. Use when adding, updating, or removing dependencies, organizing Cargo.toml sections, configuring version pinning and default features, or managing public dependencies.
license: AGPL-3.0
metadata:
  triggers:
    type: domain
    enforcement: suggest
    priority: high
    keywords:
      - cargo
      - dependency
      - Cargo.toml
      - crate
      - workspace.dependencies
      - default-features
    intent-patterns:
      - "\\b(add|update|remove|manage)\\b.*?\\b(dependency|dependencies|crate|crates)\\b"
      - "\\bCargo\\.toml\\b"
      - "\\b(public|private)\\s+dependency\\b"
---

# Cargo Dependencies Management

Guidance for adding and managing dependencies in Cargo.toml files within the HASH repository's workspace structure.

## Core Principles

**HASH uses a strict workspace dependency pattern:**

āœ… **DO:**

- Add external dependencies to workspace root `[workspace.dependencies]`
- Use caret version specifiers (e.g., `version = "1.0.0"` = `^1.0.0`)
- Set `default-features = false` for all dependencies unless specifically needed
- Use `workspace = true` in package Cargo.toml
- Organize dependencies into 4 sections with comment headers
- Use `public = true` for dependencies exposed in public API
- Align dependency names using spaces for readability

āŒ **DON'T:**

- Add version numbers directly in package Cargo.toml
- Use exact versions with `=` prefix (e.g., `=1.0.0`) in workspace root
- Enable `default-features` without considering impact
- Mix different dependency types without section comments
- Forget `public = true` for dependencies exposed in public API

## Quick Reference

### The 4-Section Pattern

Every package `Cargo.toml` must organize dependencies into these sections:

```toml
[dependencies]
# Public workspace dependencies
hash-graph-types = { workspace = true, public = true }
hashql-core      = { workspace = true, public = true }

# Public third-party dependencies
serde     = { workspace = true, public = true, features = ["derive"] }
tokio     = { workspace = true, public = true }

# Private workspace dependencies
error-stack = { workspace = true }
hash-codec  = { workspace = true }

# Private third-party dependencies
tracing     = { workspace = true }
regex       = { workspace = true }
```

**Keep all 4 section comments even if a section is empty.**

### Quick Add Process

1. **Check workspace root** - Is dependency already there?
2. **Add to workspace if needed** - With caret version `1.2.3`
3. **Determine section** - Public workspace/third-party or private?
4. **Add to package** - Use `workspace = true` (+ `public = true` if needed)

## Detailed Guides

Choose the guide that matches the task:

### [workspace-setup.md](references/workspace-setup.md)

**Use when:** Adding new dependencies to workspace root

- How to add external crates to workspace
- Version pinning with exact versions
- Default features configuration
- Workspace member paths

### [package-dependencies.md](references/package-dependencies.md)

**Use when:** Adding dependencies to a package Cargo.toml

- The 4-section organizational structure
- Public vs private dependencies
- When to use `public = true`
- Alignment and formatting rules
- Feature configuration

### [examples-reference.md](references/examples-reference.md)

**Use when:** Looking for real examples from HASH codebase

- Complete examples from `@local/codec`
- Complete examples from `@local/hashql/core`
- Optional dependencies pattern
- dev-dependencies structure

## Common Patterns

### Adding a New External Dependency

```toml
# 1. Add to workspace root Cargo.toml
[workspace.dependencies]
my-crate = { version = "1.2.3", default-features = false }

# 2. Add to package Cargo.toml (appropriate section)
[dependencies]
# Private third-party dependencies
my-crate = { workspace = true }
```

### Making a Dependency Public

```toml
# Use when the dependency appears in your public API
serde = { workspace = true, public = true, features = ["derive"] }
tokio = { workspace = true, public = true }
```

### Optional Dependencies

```toml
[dependencies]
serde = { workspace = true, optional = true, features = ["derive"] }

[features]
serde = ["dep:serde", "other-dep/serde"]
```

## References

- [workspace-setup.md](references/workspace-setup.md) - Workspace root configuration
- [package-dependencies.md](references/package-dependencies.md) - Package dependency structure
- [examples-reference.md](references/examples-reference.md) - Real codebase examples
- [Workspace Cargo.toml](../../../Cargo.toml) - Root workspace configuration
- [hash-codec/Cargo.toml](../../../libs/@local/codec/Cargo.toml) - Reference example
- [hashql-core/Cargo.toml](../../../libs/@local/hashql/core/Cargo.toml) - Reference example

Overview

This skill provides concrete guidance for adding, updating, and removing Cargo.toml dependencies across the HASH workspace. It enforces a strict workspace-first pattern, version pinning conventions, and a four-section organization for package files. Use it to keep dependency declarations consistent, readable, and safe for public API exposure.

How this skill works

The skill inspects workspace root Cargo.toml and package Cargo.toml files and recommends edits that follow HASH conventions: add external crates to [workspace.dependencies] with caret-style versions and default-features disabled, then reference them in package Cargo.toml using workspace = true. It enforces the four-section dependency layout, alignment rules, and the use of public = true for dependencies exposed in your package public API. It also flags anti-patterns like exact workspace versions, inline versions in packages, and enabling default features without review.

When to use it

  • Adding a new external crate to the workspace
  • Making a dependency visible in a package public API
  • Updating or pinning versions for workspace dependencies
  • Removing a dependency and cleaning package references
  • Reformatting package Cargo.toml to follow the four-section layout

Best practices

  • Always add external dependencies to [workspace.dependencies] with version = "x.y.z" (caret semantics) and default-features = false
  • In package Cargo.toml use workspace = true and never add version numbers directly in packages
  • Organize every package [dependencies] into the four commented sections, keeping empty section comments if needed
  • Mark dependencies used in public APIs with public = true in package entries
  • Avoid exact (=) versions in the workspace root and avoid enabling default-features unless necessary

Example use cases

  • Add new crate: declare version and default-features in workspace root, then add workspace = true under Private third-party or Public third-party in package
  • Make an optional feature: add dependency as optional in package and wire it into [features] with dep: syntax
  • Remove a crate: delete from package sections, ensure no remaining references, then remove from workspace root only after verifying no other members use it

FAQ

What if a dependency must enable default features?

Enable default-features only after evaluating impact; set default-features = true in the workspace root entry and document the reason. Prefer feature-specific enables over global default-features when possible.

Can I use exact versions in the workspace root?

No. HASH policy forbids exact (=) versions in the workspace root; use caret-style version strings instead to allow compatible updates.