fix(ci): honor the base lockfile when installing the head's exact release - #334
Merged
Merged
Conversation
…ease The npm plan's exact-release install passed --package-lock=false, which makes npm ignore the lockfile for the WHOLE tree reconciliation — not just the requested package. Every ranged dependency in the base commit's package.json re-resolved to its newest satisfying release, on the base side only. Any package that changed its rendered output between the locked release and the newest one then reds the visual diff with phantom changes no PR made — observed in the wild as icon-glyph `path d` diffs across a consumer's shared chrome on a PR that touched no UI code at all. Reproduced directly: a fixture with a dependency ranged ^1.21.0 and locked at 1.21.0, after `npm ci` then `npm install --no-save --package-lock=false <other-pkg>`, ends with 1.28.0 installed. With --package-lock=false dropped, the same sequence leaves the locked 1.21.0 in place, installs the requested package, and leaves package.json and package-lock.json byte-identical. The flag existed to guarantee the capture tree stayed clean. That guarantee now comes the same way the other package managers get it: package.json and package-lock.json join packageMetadataFiles, so the driver restores them after the exact install if npm ever writes them.
🗺️ StyleProof report📊 View the side-by-side visual report →Coverage, determinism, or report/diff consistency evidence is incomplete — repair the capture or reflow source; visual approval cannot clear this failure. |
added 6 commits
July 31, 2026 08:17
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
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.
Why does this feature exist?
Cold npm base captures installed the head's exact StyleProof release inside the adopter checkout with lockfile resolution disabled. That second install could re-resolve unrelated ranged application dependencies on the base side only, producing real rendered differences that the pull request did not cause. The fix must preserve the dependency tree created by the base commit's frozen install.
What changed?
npm ci; other package-manager paths remain unchanged.brace-expansionto the non-vulnerable lockfile release required by the Node 22 audit gate.4.7.1; the merge-to-main release workflow will publish and tag it.Behavioural Proof (with video and screenshots)
Verification Summary
.agents/project/DEFINITION_OF_DONE.md.npm run build && npm run typecheck && npm run lint && npm run format:checknpm run privacy:checknpm testnpm run test:e2eSTYLEMAP_DIR=<temporary-directory> npx playwright test --config example/store-dogfood.playwright.config.ts --workers=2npm audit --audit-level=highnpm pack --dry-run --jsonChecklist
npm run build && npm run typecheck && npm run lint && npm run format:checkpassnpm testand all 116 browser E2E tests pass.agents/project/DEFINITION_OF_DONE.mdand.agents/skills/pr-inline-screenshot-proof/SKILL.md