Feature request: static BUILD graph mode for impacted-target detection (no Bazel invocation)

[tructxn]

Problem

bazel-diff requires a full Bazel invocation to compute target hashes. In large monorepos, this is the dominant cost — Bazel's startup, analysis phase, and hash generation can take several minutes even for trivial PRs where only a handful of source files changed.

For CI workflows that need to scope test runs quickly, this overhead is the bottleneck.

Observation

In the common case — when only source files (.go, .java, .proto, .kt, etc.) change and no build configuration is touched — the reverse-dependency graph is fully derivable by statically parsing BUILD / BUILD.bazel files. No Bazel invocation is needed to answer: "which targets are transitively affected by these changed files?"

Proposed approach

Classify changed files into two buckets:

Changed file type	Action
Source files only	Walk static reverse-dep graph from BUILD files → emit impacted targets
.bzl, MODULE.bazel, WORKSPACE, go.mod, go.sum	Fall back to full bazel-diff (macros/generated targets may have changed)

The static path runs in seconds. The fallback preserves correctness when build configuration changes.

Trade-offs

• Correctness gap: Static parsing cannot handle select(), Starlark macros, or generated BUILD files. The fallback covers these cases.
• Coverage: In most feature branches, build config files don't change — the static path handles the majority of CI runs.
• Complexity: Adds a secondary code path; the fallback keeps the existing behavior as the safety net.

Request

Would the maintainers consider a --static or --fast mode that applies this strategy, with automatic fallback? Happy to discuss trade-offs or contribute.

[tinder-maxwellelliott]

Hello there,

Thank you so much for the very clear explanation of the current challenge faced when running Bazel-diff on large monorepos. The approach here does sound possible but should this live in Bazel-diff itself? From what I am reading this seems like it's as single rdeps call on those modified files. Am I misunderstanding this?

[tructxn]

Agreed that rdeps gives the same output. But a complete rdeps has to load the whole //... universe to invert the graph, and our CI runs in cold containers with no warm Bazel server — so every run would pay Bazel's full cold loading phase just to answer one query. That's what we want to avoid.