ci: guard against silently merge-corrupted lockfiles
From the PR description
What happened on #233
The backend CI job on #233 failed at npm ci with:
The
npm cicommand 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.jsonlost the comma after the branch's new"test:stack"script, right where main's"test:coverage"line was merged in.package-lock.jsonlost the two closing-brace lines of thesupertest/cookie-signatureentry, 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)
.gitattributes:merge=binaryforpackage-lock.jsonandbun.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.- CI parse-check before
npm ciin both backend and frontend jobs:JSON.parseonpackage.jsonandpackage-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
maininto a PR branch that touches dependencies, regenerate the lockfile rather than trusting the merge result, and re-runnpm cilocally. - Treat any lockfile diff a merge produced as suspect - it's generated output; only
npm installshould 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 bodyPR #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.