A Bazel Story: Cargo Splicing and the Three Lockfiles

In large Rust codebases, rules_rust’s crate_universe rule uses cargo to resolve dependencies and generate build targets. This involves cargo splicing - merging cargo manifests and computing the full rust dependency graph. However, on large projects, splicing is required to run on almost every workspace related change and it can take several minutes, slowing down workflows significantly. The root cause is cargo storing both internal and external dependencies in the same Cargo.lock file. Bazel’s lockfile could help to avoid repeated splicing, but introduces a new bottleneck: the checksum of the Cargo.lock file is embedded in MODULE.bazel.lock. Any change to internal dependencies - even unrelated to third-party crates - alters the Cargo.lock hence the checksum in the MODULE.bazel.lock. This leads to widespread and unnecessary merge conflicts across large codebases. In this talk, we’ll summarize the core problem, cargo not separating first-party and third-party code in their metadata, and explore our recent solutions in rules_rust to decouple internal deps, generate a stable Cargo.bazel.lock, and improve developer experience in large Rust codebases using Bazel via rules_rust.

Nov 11, 2025 12:00 — 12:10