Fix map_kind for generated rules so renamed kinds keep deps/data#67
Open
firestreaker wants to merge 1 commit into
Open
Fix map_kind for generated rules so renamed kinds keep deps/data#67firestreaker wants to merge 1 commit into
firestreaker wants to merge 1 commit into
Conversation
Using `# gazelle:map_kind` to rename a kind this extension generates (e.g.
`map_kind jest_test vitest_test //build:vitest_test.bzl`) produced a rule with
no deps, no data, and no load() statement, breaking dependency management.
Self-maps (X X //file) worked, which is why this went unnoticed.
Root cause: the extension pre-applied map_kind itself at generation time via a
getKind() helper, writing the mapped kind to disk directly. That bypassed
gazelle core's rename handling:
- Core never saw a builtin rule to record/remember, so it never injected the
load() for the mapped kind.
- Core's inverseMapKindResolver resets a renamed rule back to its builtin kind
before calling Imports/Resolve, but resolve.go compared r.Kind() against the
mapped name (getKind), so the comparison failed and the dep/data block was
skipped.
Let gazelle core own map_kind instead:
- generate.go: emit builtin kinds at rule creation; add unmapKind() (the
inverse of KindMap) and use it only where the code inspects on-disk kinds
(readExistingRules, pruneManagedRules, the collect-all collision check) so a
rule already renamed on disk is still recognized, merged, and pruned across
re-runs.
- resolve.go: compare r.Kind() against builtin literals (consistent with the
existing ts_project checks).
Add a golden fixture (tests/map_kind_test) covering both a fresh rename and a
re-run over an existing renamed rule. Document map_kind on the test rule in the
README.
Backward-compatible: with no map_kind (or a self-map), KindMap is empty/identity
and output is byte-identical, so the existing golden suite is unchanged.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
firestreaker
force-pushed
the
fix-map-kind-generated-rules
branch
from
deb3840 to
70257fa
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I'm adding Vitest into my Bazel project, but gazelle hardcodes the generated test target to
jest_testwhich is kinda misleading since we don't use Jest. Triedmap_kind# gazelle:map_kind jest_test vitest_test //build:vitest_test.bzlbut the renamed rule comes out with no
deps, nodata, and noload(). Getting by with a self-map (# gazelle:map_kind jest_test jest_test //build:vitest_test.bzlandjest_test = vitest_testinbuild/vitest_test.bzl) for now, but would like a cleaner fix that doesn't leave the BUILD files readingjest_test.This change has the plugin emit builtin kinds and lets gazelle do the renaming, and adds an
unmapKindhelper for the few spots that read existing on-disk rules so a rule already renamed on a previous run is still recognized and not churned