Directives
These are special comments that are placed anywhere in aBUILD file. They govern behavior as the generator visits files beneath this folder. Sub-packages can override the settings of their parent folder.
Built-in
Some directives are built-in to Gazelle, while others are specific to an extension. Unfortunately, some of the built-in directives are specific to Go, which is just a historical accident since it originally was written for Go. Here are some important ones to know:-
# gazelle:exclude patternPrevents Gazelle from processing a file or directory if the given doublestar.Match pattern matches. -
# gazelle:map_kind from_kind to_kind to_kind_loadCustomizes the kind of rules generated by Gazelle. Most commonly, this would be used to replace the rules provided by a ruleset with custom macros. For example, using a custom macro instead ofgo_library: -
# gazelle:resolve source-lang [import-lang] import-string labelSpecifies an explicit mapping from an import string to a label for Dependency resolution. For example, a go import ofexample.com/fooresolving to a target in//foo -
# gazelle:resolve_regexp source-lang [import-lang] import-string-regexp labelLikeresolve, but matches imports against an RE2 regular expression instead of an exact string — handy for mapping a whole namespace at once. Subpattern captures can be referenced in the label as$1,$2, etc. -
# gazelle:generation_mode create_and_update|update_onlyControls whether Gazelle creates newBUILDfiles or only updates existing ones. The default (create_and_update) creates new files. Setting it toupdate_onlyis useful when adopting Gazelle incrementally — Gazelle will update packages you’ve already onboarded but won’t touch directories that don’t yet have aBUILDfile.
Per-language
Individual extensions can add their own, for example, the python extension has its own directives: Python Directives And the JavaScript extension from Aspect does as well: JavaScript DirectivesAvoiding the need for directives
Directives are required when the source code doesn’t sufficiently describe what Gazelle needs to do. An alternative approach is to introduce load-bearing syntax in the source code. This way the information about the dependency graph stays in source files, not magic comments inBUILD files.
As one example, you can use triple-slash directives in TypeScript to declare “ambient” library dependencies:
/// <reference path="..." />This directive is the most common of this group. It serves as a declaration of dependency between files./// <reference lib="..." />This directive allows a file to explicitly include an existing built-in lib file.

