`make build` regenerated the version from git tags, so the tracked value
could never match what setuptools-scm computes once a release tag exists:
the tag lands on a commit whose package.json predates it. Every commit
after a release failed `prek run --all-files` — after v0.2.18 the
rebuild-from-specs hook rewrote 0.2.18 to 0.2.19 and reported a diff.
Version writing moves to scripts/set_npm_version.py, run only by
`make release-npm`; the tracked value is a 0.0.0 placeholder. It now
rejects non-release versions instead of truncating them to X.Y.Z, so a
publish from an untagged checkout can't ship a version that corresponds
to no release.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014BmsXSofh7NSy7MTVgXa6P
Summary
Using setuptools-scm means that the version is now dynamic based on the most recent git tag
This broke linting because it would regenerate the npm package version
Fix this by no longer regenerating the npm version except at publish
The committed version is pinned to 0.0.0 - publishing generates and pushes the actual version
References
First seen: #230 — linting has failed on every PR opened since v0.2.18 was tagged.
Prior workaround: c4cdf70.
Reviewer guidance
AI usage
Used Claude Code to diagnose the lint failure from the CI logs and write the fix, including splitting the version write into its own script rather than adding a flag to the spec generator. Verified with prek over all files (both normally and under a simulated post-release tag), the test suite, and manual exercise of the version guard.