bazel

Bazel Monorepos

Bazel is a graph-based build and test system for large, multi-language repositories. Treat the target graph—not folders, shell scripts, or CI job order—as the source of truth. A healthy repository has explicit dependency edges, narrow public interfaces, hermetic actions, reproducible external dependencies, and one configuration model from laptop through CI.

This skill is grounded in Bazel 9.2.0 documentation. Bazel 9 changed two fundamentals:

• Bzlmod fully replaced WORKSPACE. Bazel 9 removed the legacy WORKSPACE implementation. New Bazel 9 code must use MODULE.bazel, module extensions, and repository rules exposed through Bzlmod.
• Language rules are external modules. Previously built-in language rules—including C++—must be declared as modules and explicitly loaded. Do not assume cc_*, java_*, py_*, or other language rules exist natively.

For an existing repository, its checked-in .bazelversion, module versions, and compatibility constraints outrank this baseline. Do not silently upgrade them as part of an unrelated change.

First Inspection

Before proposing or editing Bazel configuration:

1. Read .bazelversion, MODULE.bazel, MODULE.bazel.lock, .bazelrc, .bazelignore, and any REPO.bazel or VENDOR.bazel files that exist.
2. Find BUILD, BUILD.bazel, and .bzl files in the affected tree. A nearer BUILD file creates a subpackage boundary.
3. Inspect the specific ruleset versions and their own documentation. Bazel core version and language-rules version are independent.
4. Check existing repository conventions: package granularity, visibility groups, macros, platforms, toolchain registration, CI configs, remote execution, code generation, and BUILD-file generation.
5. Use graph tools before guessing. Choose query, cquery, aquery, or mod based on the layer being investigated.
6. Make the smallest graph-preserving change, format it, and validate the narrowest affected targets before widening to //....