amal66 stops silent dependency corruption at the gate

A small safeguard makes Mike's build process much less likely to hide a broken dependency merge behind a misleading installation error.

infrastructureworkflow

Dependency files are generated records of exactly what the product needs to run. When two branches changed them at once, an automatic merge could quietly produce invalid records without raising a conflict, leaving the team chasing the wrong CI error.

Dependency lockfiles now force an explicit decision when both branches change them, rather than accepting a potentially corrupt automatic merge.
Build checks now validate the project and dependency records before installation, so a malformed file fails immediately with a useful diagnosis.

The practical change is unglamorous but important: dependency updates should be regenerated by the package manager, not hand-stitched after a merge.

So what Teams running or extending Mike should care because this reduces avoidable build failures and makes routine dependency work more dependable.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

1 commit from amal66/mike, oldest first. Source extracted verbatim from the harvested git log.

SHA Subject Author Date

e25c2637 ci: guard against silently merge-corrupted lockfiles QA Runner 2026-07-22 ↗ GitHub

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>

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 thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-1337.md from inside the repo you want the changes in.

⬇ Download capture-thread-1337.md