Skip to main content
In practice, very few people actually need to write an extension for a new language. Many extension implementations in Go already exist, and more are likely to be written. However, it’s not possible to customize the Go extensions other than by forking them or via the limited directives they expose. You can use Starlark extensions to do smaller jobs that augment what you get from the standard Gazelle binary. A few patterns we’ve seen in the wild:
  • OCI images — put a go_image target next to each Go file that has a main: go_image.axl.
  • Script targets — create a js_binary target for each entry in package.json#scripts that matches a simple pattern: package-json-scripts.axl.
  • Lint tests — add a linting test next to every library, for example a ruff_test for every package with Python code.
  • Tool config detection — look for a specific config file and generate a rule that calls the tool:
    • find webpack.config.js → generate a webpack_bundle rule
    • find jest.config.mjs → generate a jest_test target
  • Pattern-driven codegen — if a pattern exists in a source file, generate a custom extraction target. For example, i18n with go-i18n: take a naming convention like locales/**/*.json and generate message-translation targets.
  • Copy to bin — scan for sources that match a pattern and generate copy_to_bin.