> ## Documentation Index
> Fetch the complete documentation index at: https://site.aspect.build/llms.txt
> Use this file to discover all available pages before exploring further.

# Extending existing languages

> Use small Starlark Gazelle extensions to augment the stock Gazelle binary — generate OCI images, lint tests, codegen targets, and other custom rules alongside existing languages.

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](https://github.com/aspect-build/aspect-workflows-template/blob/main/template/.aspect/gazelle/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](https://github.com/aspect-build/aspect-workflows-template/blob/main/template/.aspect/gazelle/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](https://github.com/nicksnyder/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`.