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 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.
- Put a
go_image
OCI target next to each Go file that has amain
:
- Create a
py3_image
OCI target next to__main__.py
but only when it contains a# oci: build
pragma:
- Create a
js_binary
target for each entry inpackage.json#scripts
that matches a simple pattern:
- Add a linting test next to every library, for example generate
ruff_test
for every package with Python code - Look for a specific config file for a tool, and generate a rule that calls the tool. Examples:
- look for
webpack.config.js
and generate a webpack_bundle rule - look for
jest.config.mjs
and generate a jest_test target - If a pattern exists in a source file, then generate a custom extraction target. Example: i18n
- https://github.com/nicksnyder/go-i18n
- Take a naming convention like locales/**/*.json
- generate message translation targets
- Scan for sources that match a pattern and generate
copy_to_bin
Note: Aspect CLI doesn’t yet support both Starlark extensions, and custom Go extensions. We plan to use Embed GitHub when it exists, so that extensions can be provided at runtime rather than needing to re-compile Gazelle to include them.