check-bazel-files

name	check-bazel-files
description	Use after editing any Bazel file — BUILD.bazel, MODULE.bazel (including bazel/rust.MODULE.bazel), or a .bzl file — to validate the change without paying for a full build, and to auto-format it.

Checking Bazel file changes

Two fast checks after editing BUILD.bazel, MODULE.bazel, or .bzl files, run from the repository root (cd "$(git rev-parse --show-toplevel)"):

1. Validate with --nobuild

bazel build //... --nobuild

This loads and analyzes the entire workspace — catching BUILD.bazel/.bzl syntax errors, bad load()s, broken labels, and analysis-phase failures across every package — without actually building anything. It's much cheaper than a real build and covers the whole repo rather than just the directly affected targets, which matters because a bad MODULE.bazel/.bzl change (e.g. a macro used repo-wide) can break packages far from the file you touched.

Fix any errors it reports.

2. Format with buildifier

bazel run //:buildifier

Auto-formats and lint-fixes every BUILD.bazel/.bzl file in place (see the buildifier target in bazel/BUILD.bazel, aliased at //:buildifier). To only check without writing changes (e.g. to see a diff first), use bazel run //:buildifier.check instead.

Notes

• If a change touched a crate dependency, keep the Cargo and Bazel builds in line: a third-party crate lives in both the root Cargo.toml ([workspace.dependencies]) and bazel/rust.MODULE.bazel (as a crate.spec(...)), so mirror the change across both (matching package, version, features), then repin per the Repin step in .claude/CLAUDE.md (./bin/bazel-pin.sh) — --nobuild alone won't catch a stale @crate_index.
• If bazel isn't available or reachable in your current environment, see the run-in-dev-container and build-without-dfinity-infra skills.