Supporting querying for `bzlmod`-induced dependencies (for target determination, static analysis, ...)

Description of the feature request:

I was surprised to find out that there appears to be no simple programmatic way to determine e.g. that a go_ilbrary target depends on the repo's go.mod file.

I'm filing a feature request as requested from this Slack thread (2025-08-26).

@arxanas: With bzlmod and rules_go, how can I query in such a way that I'll learn that a given Go target depends on our go.MODULE.bazel and the repo's go.mod? The buildfiles(deps(...)) recommendation in the Bazel query guide doesn't seem to produce them.

[...]

@arxanas: [...] go.mod simply doesn't appear in the dependencies for Go targets? That is:

$ bazel query 'somepath(//:go.mod, //go/logger)'       
INFO: Empty results
$ bazel query 'somepath(//go/logger, //:go.mod)'
INFO: Empty results

Likewise, bazel query 'buildfiles(deps(//go/logger))' doesn't obviously include go.MODULE.bazel, despite ostensibly depending on it.

[...]

@ted-xie not a go toolchain expert. my high level view of this is that gazelle creates repository rules from the contents of go.mod. the repository rules are sort of in a different plane than the regular root module targets. hence why i said above that determing the full set would be annoying

you can use bazel mod show_extension <go_deps extension path here to get the full list of repositories constructed from go.mod via gazelle, and use that as the set in bazel query somepath

re's some bash-fu that gets you 70% of the way there:

bazelisk mod show_extension @bazel_gazelle//:extensions.bzl%go_deps | sed -rn 's/\"([^\"]*)\"/\1/p' | sort | uniq`

[...]

@dzbarsky: But yes you're right that query/aquery only know about deps starting at external repos, they don't have visibility into how those are created, which is what the module extension is essentially doing

@fmeum: The go_deps extension is reproducible and thus doesn't end up in the regular lockfile

With recent versions of Bazel, it will be stored in the lockfile in the output base

It's true that we lack visibility into what repo rules and module extensions do. Part of the problem is that they can do anything really (run arbitrary executables). But we could expose their runtime dependencies in some way

Could you file a feature request for this?

Which category does this issue belong to?

CLI, External Dependency

What underlying problem are you trying to solve with this feature?

• Target determination (i.e. determining which targets to rebuild given a code change). Right now, you may have to hardcode some rules like "all Go targets depend on go.mod" or "all targets depend on the bzlmod lockfile".
• Static analysis / data-flow analysis. It's not easy to programmatically infer that go.mod flows into Go targets.

Which operating system are you running Bazel on?

macOS

What is the output of bazel info release?

release 8.3.1

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?

Have you found anything relevant by searching the web?

Does not currently seem possible as per Slack thread.

Any other information, logs, or outputs that you want to share?

No response