# Aleksey Kladov - Large Rust Workspaces (Highlights)  ## Metadata **Cover**:: https://readwise-assets.s3.amazonaws.com/static/images/article2.74d541386bbf.png **Source**:: #from/readwise **Zettel**:: #zettel/fleeting **Status**:: #x **Authors**:: [[Aleksey Kladov]] **Full Title**:: Large Rust Workspaces **Category**:: #articles #readwise/articles **Category Icon**:: 📰 **URL**:: [matklad.github.io](https://matklad.github.io//2021/08/22/large-rust-workspaces.html) **Host**:: [[matklad.github.io]] **Highlighted**:: [[2021-08-23]] **Created**:: [[2022-09-26]] **Tags**:: #rust #favorite ## Highlights - Everything else (including rust-analyzer “main” crate) is nested one-level deep under crates/. The name of each directory is equal to the name of the crate Example ``` [workspace] members = ["crates/*"] ``` - Flat Is Better Than Nested - Make the root of the workspace a virtual manifest. It might be tempting to put the main crate into the root, but that pollutes the root with src/, requires passing --workspace to every Cargo command, and adds an exception to an otherwise consistent structure. - Don’t succumb to the temptation to strip common prefix from folder names. If each crate is named exactly as the folder it lives in, navigation and renames become easier. - For large projects a lot of repository bloat often comes from ad-hoc automation — Makefiles and various prepare.sh scripts here and there. To avoid both the bloat and proliferation of ad-hoc workflows, write all automation in Rust in a dedicated crate. One pattern useful for this is cargo xtask. - Use version = "0.0.0" for internal crates you don’t intend to publish. If you do want to publish a subset of crates with proper semver API, be very deliberate about them. It probably makes sense to extract all such crates into a separate top-level folder, libs/. It makes it easier to check that things in libs/ don’t use things from crates/.