Skip to content

fix(ship): sync package-lock.json version alongside package.json#1862

Open
oharriehausen wants to merge 1 commit into
garrytan:mainfrom
oharriehausen:fix/ship-lockfile-sync-cli
Open

fix(ship): sync package-lock.json version alongside package.json#1862
oharriehausen wants to merge 1 commit into
garrytan:mainfrom
oharriehausen:fix/ship-lockfile-sync-cli

Conversation

@oharriehausen
Copy link
Copy Markdown

Problem

/ship Step 12 (carved into bin/gstack-version-bump by #1806) bumps VERSION and package.json's version but leaves package-lock.json's version field stale. Every JS-repo ship then carries a spurious 2-line package-lock.json diff, and npm ci warns on the version mismatch.

This is the same bug #1757 fixed against the old inline-bash surface. #1757 is now CONFLICTING because #1806 moved that code into the CLI, so it can't be merged as-is. This PR re-ports the fix onto the new CLI surface — it's what #1757 needs to become.

Fix

writeLockVersion() mirrors writePkgVersion()'s semantics:

  • Silent skip when package-lock.json is absent (yarn/pnpm/bun/no JS).
  • Malformed lockfile → exit 2, no corrupted write.
  • I/O failure after package.json already written → exit 3 (half-write).
  • Updates both top-level version and packages[""].version (lockfileVersion 3 stores the root version in two places).

Wired through both write (FRESH bump) and repair (DRIFT_STALE_PKG). The state classifier is intentionally untouched: a stale lockfile root version never blocks runtime, so it's opportunistically synced but is not a halt condition.

Tests

  • 3 existing write/repair assertions updated for the new packageLock field.
  • 3 new tests cover lockfile sync on write + repair plus the malformed-lockfile exit-2 guard.
  • Full gstack-version-bump + ship-version-sync suites: 32 pass, 0 fail.

Built on top of v1.55.1.0 (c43c850); clean, no conflicts.

Closes the gap left by #1757.

/ship Step 12 (carved into bin/gstack-version-bump by garrytan#1806) bumps VERSION
and package.json's version but leaves package-lock.json's version field
stale. Every JS-repo ship then carries a spurious 2-line package-lock.json
diff, and `npm ci` warns on the version mismatch. Same bug garrytan#1757 fixed
against the old inline-bash surface; garrytan#1757 is now CONFLICTING since garrytan#1806
moved the code, so this re-ports the fix onto the CLI.

writeLockVersion() mirrors writePkgVersion()'s semantics:
- Silent skip when package-lock.json is absent (yarn/pnpm/bun/no JS).
- Malformed lockfile -> exit 2, no corrupted write.
- I/O failure after package.json already written -> exit 3 (half-write).
- Updates both top-level `version` and packages[""].version
  (lockfileVersion 3 stores the root version in two places).

Wired through both `write` (FRESH bump) and `repair` (DRIFT_STALE_PKG).
The state classifier is intentionally untouched: a stale lockfile root
version never blocks runtime, so it is opportunistically synced but is
not a halt condition.

Tests: 3 existing write/repair assertions updated for the new packageLock
field; 3 new tests cover lockfile sync on write + repair plus the
malformed-lockfile exit-2 guard. Full suite: 32 pass.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@trunk-io
Copy link
Copy Markdown

trunk-io Bot commented Jun 4, 2026

Merging to main in this repository is managed by Trunk.

  • To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

@buddy7599bot
Copy link
Copy Markdown

Validated — this looks correct and is the canonical surface for the lockfile-sync fix. Confirming the lineage so triage is clean:

No competing open PR found on this path. One small nicety (non-blocking): a test asserting the lockfile is left untouched when only VERSION/package.json exist (the yarn/pnpm/bun "no lockfile" path) would lock in the silent-skip behavior, if not already covered.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants