MCPcopy Index your code
hub / github.com/bazel-contrib/bazel-gazelle

github.com/bazel-contrib/bazel-gazelle @v2.0.0-2

Chat with this repo
repository ↗ · DeepWiki ↗ · release v2.0.0-2 ↗ · + Follow
1,274 symbols 4,406 edges 374 files 466 documented · 37% updated 2d agov0.51.3 · 2026-06-04★ 1,402385 open issues
What it actually does AI analysis from the code graph — generated when you open this
loading…
README

Gazelle build file generator

Gazelle is a build file generator for Bazel projects. It can create new BUILD.bazel files for a project that follows language conventions, and it can update existing build files to include new sources, dependencies, and options. Gazelle natively supports Go and protobuf, and it may be extended to support new languages and custom rule sets.

Gazelle may be run by Bazel using the gazelle rule or it may be installed and run as a command line tool. Gazelle can also generate build files for external repositories as part of the go_repository rule.

Gazelle is under active development. Its interface and the rules it generates may change. Gazelle is not an official Google product.

Mailing list: bazel-go-discuss

Slack: #go on Bazel Slack, #bazel on Go Slack

rules_go and Gazelle are getting community maintainers! If you are a regular user of either project and are interested in helping out with development, code reviews, and issue triage, please drop by our Slack channels (linked above) and say hello!

See also:

Supported languages

Gazelle can generate Bazel BUILD files for many languages:

  • Go: Go supported is included here in bazel-gazelle, see below.
  • Haskell: Tweag's rules_haskell has two extensions: gazelle_cabal, for generating rules from Cabal files, and gazelle_haskell_modules for even more fine-grained build definitions.
  • Java: bazel-contrib's rules_jvm extensions include a gazelle extension for generating java_library, java_binary, java_test, and java_test_suite rules.
  • JavaScript / TypeScript: Aspect provides JavaScript and TypeScript Support. BenchSci's rules_nodejs_gazelle supports generating ts_project, js_library, jest_test, and web_asset rules, and is able to support module bundlers like Webpack and Next.js.
  • Kotlin: Aspect Build provides some Kotlin Support. Still under development, please check the README for currently available features.
  • Protocol Buffers: Support for the proto_library rule. Language-specific rules like go_proto_library are supported by other language extensions.
  • Python: rules_python has an extension for generating py_library, py_binary, and py_test rules.
  • R: rules_r has an extension for generating rules for R package builds and tests.
  • Rust: gazelle_rust is an extension for generating rules_rust targets.
  • Starlark: bazel-skylib has an extension for generating bzl_library rules. See bazel_skylib/gazelle/bzl.
  • Swift: swift_gazelle_plugin has an extension for generating swift_library, swift_binary, and swift_test rules. It also includes facilities for resolving, downloading and building external Swift packages for a Bazel workspace.
  • C/C++: gazelle_cc has an extension for cc_* rules.

If you know of an extension which could be linked here, please open a PR!

More languages can be added by Extending Gazelle. Chat with us in the #gazelle channel on Bazel Slack if you'd like to discuss your design.

If you've written your own extension, please consider open-sourcing it for use by the rest of the community. Note that such extensions belong in a language-specific repository, not in bazel-gazelle. See discussion in #1030.

Setup

Bzlmod

See the Go Bzlmod docs.

The full documentation for the go_deps extension is in extensions.md.

WORKSPACE

To use Gazelle in a new project, add the bazel_gazelle repository and its dependencies to your WORKSPACE file and call gazelle_dependencies. It should look like this:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

http_archive(
    name = "io_bazel_rules_go",
    integrity = "sha256-M6zErg9wUC20uJPJ/B3Xqb+ZjCPn/yxFF3QdQEmpdvg=",
    urls = [
        "https://mirror.bazel.build/github.com/bazelbuild/rules_go/releases/download/v0.48.0/rules_go-v0.48.0.zip",
        "https://github.com/bazelbuild/rules_go/releases/download/v0.48.0/rules_go-v0.48.0.zip",
    ],
)

http_archive(
    name = "bazel_gazelle",
    integrity = "sha256-12v3pg/YsFBEQJDfooN6Tq+YKeEWVhjuNdzspcvfWNU=",
    urls = [
        "https://mirror.bazel.build/github.com/bazelbuild/bazel-gazelle/releases/download/v0.37.0/bazel-gazelle-v0.37.0.tar.gz",
        "https://github.com/bazelbuild/bazel-gazelle/releases/download/v0.37.0/bazel-gazelle-v0.37.0.tar.gz",
    ],
)


load("@io_bazel_rules_go//go:deps.bzl", "go_register_toolchains", "go_rules_dependencies")
load("@bazel_gazelle//:deps.bzl", "gazelle_dependencies", "go_repository")

############################################################
# Define your own dependencies here using go_repository.
# Else, dependencies declared by rules_go/gazelle will be used.
# The first declaration of an external repository "wins".
############################################################

go_rules_dependencies()

go_register_toolchains(version = "1.20.5")

gazelle_dependencies()

gazelle_dependencies supports optional arguments go_env (dict-mapping) to set project specific go environment variables and go_env_inherit (list of names) to copy selected variables from the host environment. This is useful when dependency fetching relies on runtime-provided authentication, proxy settings, or repository configuration that should not be checked into source control. If you are using a WORKSPACE.bazel file, you will need to specify that using:

gazelle_dependencies(go_repository_default_config = "//:WORKSPACE.bazel")

Add the code below to the BUILD or BUILD.bazel file in the root directory of your repository.

Important: For Go projects, replace the string after prefix with the portion of your import path that corresponds to your repository.

load("@bazel_gazelle//:def.bzl", "gazelle")

# gazelle:prefix github.com/example/project
gazelle(name = "gazelle")

After adding this code, you can run Gazelle with Bazel.

bazel run //:gazelle

This will generate new BUILD.bazel files for your project. You can run the same command in the future to update existing BUILD.bazel files to include new source files or options.

You can write other gazelle rules to run alternate commands like update-repos.

gazelle(
    name = "gazelle-update-repos",
    args = [
        "-from_file=go.mod",
        "-to_macro=deps.bzl%go_dependencies",
        "-prune",
    ],
    command = "update-repos",
)

You can also pass additional arguments to Gazelle after a -- argument.

bazel run //:gazelle -- update-repos -from_file=go.mod -to_macro=deps.bzl%go_dependencies

After running update-repos, you might want to run bazel run //:gazelle again, as the update-repos command can affect the output of a normal run of Gazelle.

To verify that all BUILD files are update-to-date, you can use the gazelle_test rule.

load("@bazel_gazelle//:def.bzl", "gazelle_test")

gazelle_test(
    name = "gazelle_test",
    workspace = "//:BUILD.bazel", # a file in the workspace root, where the gazelle will be run
)

However, please note that gazelle_test cannot be cached.

Usage

Command line

In most cases, you'll invoke Gazelle through Bazel using the gazelle rule:

bazel run //:gazelle

To run Gazelle in specific directories, or with additional flags:

bazel run //:gazelle -- [flags...] [directories...]

If you build and install a Gazelle binary, you can also invoke it directly without bazel run.

gazelle [fix|update] [flags...] [directories...]

Configuration directives

Gazelle can be configured with directives, which are written as top-level comments in build files. Most options that can be set on the command line can also be set using directives. Some options can only be set with directives.

Directive comments have the form # gazelle:key value. For example:

load("@io_bazel_rules_go//go:def.bzl", "go_library")

# gazelle:prefix github.com/example/project
# gazelle:build_file_name BUILD,BUILD.bazel

go_library(
    name = "go_default_library",
    srcs = ["example.go"],
    importpath = "github.com/example/project",
    visibility = ["//visibility:public"],
)

Directives apply in the directory where they are set and in subdirectories. This means, for example, if you set # gazelle:prefix in the build file in your project's root directory, it affects your whole project. If you set it in a subdirectory, it only affects rules in that subtree.

Reference

For a full reference on Gazelle's configuration directives, flags, and rules, see the following pages:

Extensions defined outside this repo provide their own references.

Lazy indexing in fix and update

By default, fix and update read all build files in a repo to build an index of library rules (see Dependency resolution) when Gazelle starts. This can take a long time on a large repo. To avoid this problem, Gazelle can lazily index specific directories, with help from extensions that support lazy indexing.

To configure lazy indexing with Go, add go_search directives like this:

# gazelle:go_search third_party/go
# gazelle:go_search replace/b example.com/b

These directives point to directories that contain Go code outside the current module, with an optional package prefix. go_search directives are not necessary if you're following regular Go module conventions or are using a Go vendor directory.

To configure lazy indexing with protobuf, add proto_search directives like this:

# gazelle:proto_search third_party/proto api

The two arguments are a prefix to remove from the import path and a prefix to add. These correspond to the strip_import_prefix and import_prefix attributes of proto_library. They tell Gazelle how to transform an import path read from a .proto source file into a repo-root-relative path to a directory that may contain the imported file.

To use Gazelle with lazy indexing, run with -r=false -index=lazy, and pass the directories to update on the command line.

gazelle -r=false -index=lazy path/to/dir1 path/to/dir2

You can configure your gazelle Bazel target to pass these flags automatically:

load("@gazelle//:def.bzl", "gazelle", "gazelle_binary")

gazelle(
    name = "gazelle",
    command = "fix",
    extra_args = ["-r=false", "-index=lazy"],
    gazelle = ":gazelle_binary",
)

gazelle_binary(
    name = "gazelle_binary",
    ...
)

Compatibility with Go

Gazelle is compatible with supported releases of Go, per the Go Release Policy. The Go Team officially supports the current and previous minor releases. Older releases are not supported and don't receive bug fixes or security updates.

Gazelle may use language and library features from the oldest supported release.

Dependency resolution

One of Gazelle's most important jobs is resolving library import strings (like import "golang.org/x/sys/unix") to Bazel labels (like @org_golang_x_sys//unix:go_default_library). Gazelle follows the rules below to resolve dependencies:

  1. If the import to be resolved is part of a standard library, no explicit dependency is written. For example, in Go, you don't need to declare that you depend on "fmt".
  2. If a # gazelle:resolve directive matches the import to be resolved, the label at the end of the directive will be used.
  3. If proto rule generation is enabled, special rules will be used when importing certain libraries. These rules may be disabled by adding # gazelle:proto disable_global to a build file (this will affect subdirectories, too) or by passing -proto disable_global on the command line.
    1. Imports of Well Known Types are mapped to rules in @io_bazel_rules_go//proto/wkt.
    2. Imports of github.com/golang/protobuf/ptypes, descriptor, and jsonpb are mapped to special rules in `@com_github_golang_protobuf

Extension points exported contracts — how you extend this code

Resolver (Interface)
Resolver is an interface that language extensions can implement to resolve dependencies in rules they generate. [6 implementers]
resolve/index.go
Configurer (Interface)
Configurer is the interface for language or library-specific configuration extensions. Most (ideally all) modifications [11 …
config/config.go
Language (Interface)
Language describes an extension for Gazelle that provides support for a set of Bazel rules. Languages are used primaril [5 …
language/lang.go
LifecycleManager (Interface)
LifecycleManager allows an extension to initialize and free up resources at different points. Extensions should embed Ba [3 …
language/lifecycle.go
BzlExprValue (Interface)
BzlExprValue is implemented by types that have custom translations to Starlark values. [3 implementers]
v2/rule/value.go
RepoUpdater (Interface)
RepoUpdater may be implemented by languages that support updating repository rules that provide named libraries. EXPERI [1 …
language/update.go
WalkFunc (FuncType)
WalkFunc is a callback called by Walk in each visited directory. dir is the absolute file system path to the directory
walk/walk.go
CrossResolver (Interface)
CrossResolver is an interface that language extensions can implement to provide custom dependency resolution logic for o [1 …
resolve/index.go

Core symbols most depended-on inside this repo

SetAttr
called by 124
v2/rule/rule.go
Name
called by 114
resolve/index.go
Kind
called by 85
v2/rule/rule.go
CreateFiles
called by 56
testtools/files.go
AttrString
called by 40
v2/rule/rule.go
NewRule
called by 38
rule/rule.go
getGoConfig
called by 37
language/go/config.go
AttrStrings
called by 36
v2/rule/rule.go

Shape

Function 732
Method 361
Struct 136
TypeAlias 30
Interface 11
FuncType 4

Languages

Go100%
C1%

Modules by API surface

v2/rule/rule.go97 symbols
language/go/package.go34 symbols
language/go/config.go34 symbols
repo/remote.go27 symbols
walk/walk_test.go26 symbols
v2/rule/value.go26 symbols
cmd/gazelle/integration_test.go25 symbols
v2/cmd/gazelle/update/update.go23 symbols
language/go/generate.go22 symbols
config/config.go22 symbols
walk/config.go21 symbols
resolve/index.go21 symbols

For agents

$ claude mcp add bazel-gazelle \
  -- python -m otcore.mcp_server <graph>

⬇ download graph artifact

Ask about this repo answers extend the page