fix(ci): stop generated files from failing every release PR

[jamesyong-42]

Release PR #80 (0.5.22) fails CI on check (ubuntu-latest) at the Generated files are current step. This fixes the cause.

What's actually wrong

release-please bumps package.json and Cargo.toml but cannot run a build, so the two generated files that embed the version go stale the moment it opens a release PR. pnpm build then regenerates them and git diff --exit-code fails. Both are in #80's failing diff:

diff --git a/Cargo.lock b/Cargo.lock
diff --git a/crates/spaghetti-napi/index.js b/crates/spaghetti-napi/index.js

Version stamping landed in a6c88cf (#79), which is in this release — so 0.5.22 is the first release PR that could hit this, and every future one would too. main passes because there the versions agree; only the bumped release branch diverges.

Not caused by the org transfer.

Cargo.lock — bumped by release-please

A lockfile must stay committed, so it gets a toml extra-file entry.

The jsonpath matches on @.name.value, not @.name. The updater parses TOML into position-annotated nodes ({start, end, value}), so the intuitive form matches nothing and silently no-ops with only a No entries modified warning — it would have looked fixed and failed the next release anyway. I caught this by running release-please's GenericToml updater directly against the real lockfile:

jsonpath	result
$.package[?(@.name==='spaghetti-napi')].version	0 matches, no-op
$.package[?(@.name.value==='spaghetti-napi')].version	1 match → /package/106/version

End-to-end the updater rewrites exactly one line (L927), preserves Cargo's generated header, and leaves the line count identical.

Matching by name rather than array index is deliberate: [[package]] is sorted alphabetically, so an index would silently retarget a different crate as dependencies change.

index.js — no longer committed

napi build stamps the version into a per-platform guard in ~50 places; no updater can track that, and the file is pure generated output. History already carries a manual chore(napi): regenerate loader for 0.5.20 after native rebuild commit — this removes that chore permanently.

It is still published. files in package.json is an allowlist that overrides .gitignore, verified with npm pack --dry-run:

npm notice 5.0kB  index.d.ts
npm notice 25.1kB index.js      <-- present
npm notice 4.4MB  spaghetti.darwin-arm64.node

Every publish path builds before packing, and pnpm -r build builds the crate before the SDK, so CI and fresh clones generate it ahead of any consumer.

index.d.ts stays committed — it is the reviewable API surface and carries no version. Confirmed neither it nor parse-worker.js contains a version string, so the drift check keeps full teeth for real codegen rot.

This mirrors truffle, which already gitignores its napi loader for exactly this reason.

Verification

• git diff --exit-code -- Cargo.lock crates/spaghetti-napi packages/sdk/src/workers/parse-worker.js → clean
• npm pack --dry-run → loader present in tarball
• GenericToml unit-tested against the committed config's jsonpath → 1 line changed
• Rationale documented in RELEASING.md and the ci.yml comment, since JSON can't hold a comment and @.name.value invites a wrong "simplification"

After merge

release-please will regenerate #80 against the new config; its CI should then pass. That release is also the first real exercise of the retargeted npm OIDC trusted publishers.

🤖 Generated with Claude Code