ci: guard against silently merge-corrupted lockfiles

✅ merged · #240 · open-legal-products/mike ← amal66/mike · opened 3mo ago by amal66 · merged 3mo ago by willchen96 · +20 across 2 files · ↗ on GitHub

From the PR description

What happened on #233

The backend CI job on #233 failed at npm ci with:

The npm ci command can only install with an existing package-lock.json ...

The lockfile did exist. The real cause: a Merge branch 'main' commit on the PR branch auto-merged backend/package.json and backend/package-lock.json - both modified on each side - and git's line-level text merge spliced the two versions into syntactically invalid JSON without raising a conflict:

  • package.json lost the comma after the branch's new "test:stack" script, right where main's "test:coverage" line was merged in.
  • package-lock.json lost the two closing-brace lines of the supertest/cookie-signature entry, where both sides had inserted different package entries at the same alphabetical position.

npm (Arborist) swallows the lockfile parse error and treats the file as absent, hence the misleading "no existing package-lock.json" message. Since git saw no conflict, GitHub showed the branch as cleanly mergeable - nothing looked wrong until npm tried to read the file. (The immediate breakage is fixed on the #233 branch itself; this PR is the prevention.)

Prevention (this PR)

  1. .gitattributes: merge=binary for package-lock.json and bun.lock. Generated files shouldn't be text-merged. With the binary driver, any concurrent change surfaces as an explicit conflict, and the documented resolution is to regenerate (git checkout origin/main -- package-lock.json && npm install) instead of hand-merging.
  2. CI parse-check before npm ci in both backend and frontend jobs: JSON.parse on package.json and package-lock.json. If corruption ever lands anyway, CI fails in one second with the actual reason instead of npm's misleading usage error.

Habits that keep this away

  • After merging main into a PR branch that touches dependencies, regenerate the lockfile rather than trusting the merge result, and re-run npm ci locally.
  • Treat any lockfile diff a merge produced as suspect - it's generated output; only npm install should write it.

Verified: node -e "JSON.parse(...)" passes on both files at main; the workflow change is additive and job-local, so it's safe on trees with or without the other pending test PRs.

🤖 Generated with Claude Code

Our analysis

Guard lockfiles against silent merge corruption — read the full analysis →

Think the analysis missed something the PR description covers?

Commits in this PR (1)

SHA Subject Author Date
e25c2637 ci: guard against silently merge-corrupted lockfiles QA Runner 2026-07-22 ↗ GitHub
commit body
PR #233's CI failed with "npm ci can only install with an existing
package-lock.json" even though the file existed: a "Merge branch 'main'"
commit had auto-merged backend/package.json and package-lock.json into
invalid JSON with no conflict raised, and npm reports an unparseable
lockfile as if it were missing.

Two guards: .gitattributes marks package-lock.json/bun.lock merge=binary so
concurrent lockfile changes surface as explicit conflicts (resolve by
regenerating, never hand-merging), and CI parse-checks package.json and the
lockfile before npm ci so any corruption that still lands fails with the
real reason.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Capture this PR into my fork

Download a Markdown prompt that tells Claude how to port every commit in this PR into your working tree. Run it via claude -p < capture-pull-240.md from inside the repo you want the changes in.

⬇ Download capture-pull-240.md