Keep the lockfile version in step with releases - #144
Merged
Merged
Conversation
Co-authored-by: Cursor <cursoragent@cursor.com>
noisyneuron
marked this pull request as ready for review
September 17, 2026 11:51
chadlawlis
approved these changes
Sep 17, 2026
chadlawlis
left a comment
chadlawlis
left a comment
Contributor
There was a problem hiding this comment.
Thanks for this – makes sense and works as expected.
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
2 participants
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.
Releasing bumps the package version without touching the lockfile's copy of it, so the two have drifted since 1.10.2 and only get reconciled when someone happens to run an install and commit the noise in an unrelated PR. The release script now syncs the lockfile immediately after versioning and commits it alongside the docs and changeset metadata, and
npm run checkfails whenever the two versions disagree, so the drift can't reappear silently by any route. The lockfile is also brought up to the current 1.11.0.Test plan
npm run check:lockfile. You should see it report that the lockfile matches1.11.0.versioninpackage-lock.jsonto any other value and runnpm run check:lockfileagain. Observe that it fails, names both versions, and tells you to runnpm install --package-lock-only.Made with Cursor