Repository navigation
chore(ast-grep): upgrade to ast-grep 0.51.0 - #545
Conversation
|
@claude /review |
|
Claude finished @theCodeDrift's task in 3m 58s —— View job Review complete
Review mode: incremental — read 0 prior review thread(s) before reviewing. SummaryThis PR bumps the vendored ast-grep pin to 0.51.0 and lands the follow-on work needed to make that land green: a Two findings, both posted inline:
Everything else — the pin bump itself, the capabilities/schema updates, the vendor-contract test additions for the Haskell rename, the trailing- |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
The pin bump alone left two contract pins red. ast-grep 0.50.0 added Zig, so AST_GREP_LANGUAGES gains it. 0.51.0 replaced serde_yaml with serde-saphyr, which drops the backticks from the severity error; the pin records the new wording. No Taskless user reads that text, since validate rejects the severity against the schema first. Two measured changes no test caught are now pinned. A rule file ending in a stray `---` loads on 0.51.0, where 0.45.3 exited 8 and took every sg rule in the config down with it. And tree-sitter-haskell 0.24.1 renamed the kind `type_synomym` to `type_synonym`, the only kind or field that changed across the two grammars' node-types.json; a rule on the old spelling now exits 8. That rename is fixed deterministically. `update --rules` now applies rule migrations keyed on the engine versions the rules were last reconciled against (`rules.engines`), not on the scaffold version, so a rewrite that touches a handful of projects never bumps every project's scaffold and breaks pinned CLIs in CI. Migrations run before the stamp, are idempotent, edit bytes in place, and must only rewrite shapes the service never issued; the service has issued no rule on the old Haskell kind. `update --json` lists pending migrations, and `update --rules` refuses with SCAFFOLD_MIGRATION_REQUIRED when the layout is behind. The ledger gains a 0.13.3 entry and the update topic moves to v18.
Only a missing sg rules tree means there is nothing to rewrite. Any other readdir error was read the same way, and the stamp that follows would have recorded the rename as applied with no later run retrying it.
405297a to
5471e2e
Compare
Both findings are handled in 5471e2e. The — AI Coding Agent |
1 participant
Stack (root → tip):
Upstream ast-grep is ahead of the version this repository pins.
This moves every
@ast-grep/cli*pin inpackages/cli/package.jsonfrom
0.45.3to0.51.0and regeneratespnpm-lock.yaml. The pins move together on purpose: the platformpackages are selected by optional dependency, so a straggler left at
the old version is a different ast-grep on one platform than on the
others.
sg-detect.cjsfails the run rather than open a partial bump.The rewrite replaces a version string in pins it can already
enumerate and refuses if the count does not match, so it cannot add a
dependency or reformat the file. It also moves
AST_GREP_VERSIONincapabilities.tsand refetchessrc/generated/ast-grep-rule-schema.jsonfor the 0.51.0 tag, and the workflow ran
engine-version-consistencyagainst the result before pushing. Whatthis does not carry is judgment: if
ast-grep-vendor-contractis red on this pull request, ast-grep 0.51.0 added a language
or changed a measured behaviour, and that edit, the
updateledger,and the release note's prose belong in a child pull request.
This pull request rolls: if upstream releases again before it merges,
the branch, title, and body are rewritten to the newer version rather
than a second pull request being opened. Push a commit to the branch
and that stops — the workflow will not force-push over a commit it did
not write.
Upstream release notes — 0.51.0
https://github.com/ast-grep/ast-grep/releases/tag/0.51.0
Contains #548
#545 moves the
@ast-grep/cli*pins to 0.51.0. This is what makes that bump correct, plus the deterministic rule migration it turned out to need.What the pin bump alone left red
sg run -h. Added toAST_GREP_LANGUAGES; probed through a config,Zig,zigandZIGall load and match, and it has no extension alias.validaterejects the severity against the schema first.Measured, and not caught by any test
20 YAML edge cases were run against both binaries (duplicate keys, anchors, merge keys, tags, null relations, multi-document files, YAML 1.1 booleans, unknown keys, and others). Only error wording changed, except for one:
---, beside a second ruleThat is a relaxation
checkusers will see, so it is pinned underscan exit codes.tree-sitter-haskell 0.23.1 → 0.24.1 renamed one kind,
type_synomym→type_synonym(upstreamfix!: typo). Diffed across both grammars'node-types.json: of 187 named kinds this is the only one that changed, and no field changed. A rule on the old spelling exits 8, which takes every sg rule incheckdown with it. Pinned both ways in a newHaskell names a type synonymblock.The rest needs nothing: the custom-language opt-in and trust policy (#2960, #2971, #2972) is unreachable because we assemble our own config with no
customLanguages; null relation fields are refused identically on both versions, and our schema rejects them first; the vendored rule schema changed only its provenance comment; outline output is not exposed.Rule migrations, keyed on engine version rather than on the scaffold
The Haskell rename is mechanical, so it is applied rather than handed to an agent. It is not a scaffold migration: 0011 already shipped, so a 0012 would move every project's scaffold to 12 and make every pinned CLI refuse its project with
SCAFFOLD_VERSION_MISMATCH, for a typo that affects almost no one.Instead,
update --rulesapplies rule migrations keyed onrules.engines, the engine versions the rules were last reconciled against, which it records and nothing else does:engineVersionand the bundled engine is at or above it; a project with no recorded engines gets all of them. Each engine is keyed on its own version.update --jsonlists what is pending (ruleMigrations);update --rulesnames every file it wrote (migrated).update --rulesnow refuses withSCAFFOLD_MIGRATION_REQUIREDwhen the layout is behind, so a rewrite never writes into an old layout.The contract each migration must meet is stated in
rule-migrate.ts: idempotent, edit bytes in place rather than parse and re-serialize, and rewrite only shapes the service never issued, or has already migrated in its own corpus. A rewritten issued rule reads as "edited since Taskless issued it", andrule restorewrites the old bytes straight back; accepting other bytes client-side would be a signature bypass. The service has issued no rule namingtype_synomym, confirmed on the Cloud side.The Haskell migration touches only rules whose
languageresolves to Haskell (thehsalias included), rewrites onlykind:values (block, flow, quoted, list item), and never reads.tests/. Vale migrations for #546 add one file and one registry line.Ledger and changeset
update.mdgains aMigrating to 0.13.3section telling agents not to rename by hand, step 5 explains the rewrites, and the error table lists the new refusal. Topic v17 → v18. The changeset is grown in place, stillpatch.Typecheck, lint, and the full CLI suite pass: 136 files, 2487 tests.
Stacked on #545. Merges down into
vendor/ast-grep/upgrade.Refs #545