GeezerVison

LLM Description written by Claude Code:claude-opus-5-5

Fixes #360

Summary

With a lockfile 9.0 project on pnpm 10.5+ that keeps its overrides: in pnpm-workspace.yaml, vendor / scan --mode vendored no longer adds a package.json pnpm.overrides copy. That copy replaced the user's workspace overrides on pnpm 10. Before this change, vendor reported success, but every pnpm install --frozen-lockfile then failed with ERR_PNPM_LOCKFILE_CONFIG_MISMATCH, and a re-lock silently dropped the user's overrides. Now only the workspace file and the lock are wired.

The diff is 2 files (vendor/pnpm_lock.rs and tests/e2e_vendor_pnpm_build.rs). An earlier commit on this branch reformatted the whole workspace with rustfmt by mistake. The second commit, eb4ddc6, reverts all 130 unrelated files to main.

Root cause

The vendored pnpm 9.0 writer (vendor_pnpm_dialect) always called apply_pkg_override. That function writes a back-compat package.json pnpm.overrides entry for pnpm versions that read overrides only from package.json. On pnpm 10.5–10.x, a package.json pnpm.overrides field takes the place of the workspace-file overrides: instead of merging with them. The lock socket-patch wrote (the user's overrides plus ours) then no longer matched the override set pnpm computes (ours only).

Fix

New helper workspace_overrides_govern. It returns true only when all three hold:

• package.json has no pnpm.overrides of its own;
• pnpm-workspace.yaml has a block overrides: section with a user-authored (non-vendored) key;
• the lock's overrides: section records that key.

The third condition is direct evidence that the pnpm which wrote this lock reads the workspace file. pnpm 9 and 10.0–10.4 ignore workspace overrides and never record them, so on those versions the package.json copy is still written, as before.

When the helper returns true, the package.json step is skipped: no write and no pnpm_pkg_override wiring record. Revert, rollback and the in-sync re-run all follow the wiring records, so they need no change. The legacy (pnpm 7/8) dialect is untouched.

Test evidence

Each regression test failed before the fix and passes with it.

What the e2e test does:

1. Installs a real project with workspace overrides: {is-number: 7.0.0} and vendors left-pad.
2. Asserts package.json is byte-identical after vendoring.
3. Copies the committable files to a fresh checkout and runs pnpm install --frozen-lockfile with an empty store. It asserts the install succeeds, installs the patched left-pad bytes, and still resolves is-odd's is-number to 7.0.0, so the user's override holds.
4. Runs vendor --revert and asserts package.json, pnpm-workspace.yaml and pnpm-lock.yaml are restored byte for byte.

These control tests pass, showing the existing behavior is kept:

• workspace_overrides_unrecorded_in_lock_keep_the_package_json_copy: pnpm 9 / 10.0–10.4 locks still get the copy.
• existing_package_json_overrides_keep_the_package_json_copy

Commands run locally:

• cargo clippy --workspace --all-features -- -D warnings: clean.
• cargo fmt: the changed hunks are rustfmt-formatted. cargo fmt --all -- --check is not clean on main itself (about 130 files), and CI runs no fmt check.
• cargo test --workspace --all-features --no-fail-fast: 9728 passed, 12 failed. All 12 are pre-existing permission-based write/remove-failure tests (e.g. vendor_state_write_failure_reports_failed_event uses chmod 0o555). They can't fail as intended in this sandbox because it runs as root, and none touch pnpm. CI runs as non-root and is green.
• cargo test -p socket-patch-cli --all-features --test e2e_vendor_pnpm_build: 17 passed (1 ignored), re-run on eb4ddc6.
• cargo test -p socket-patch-core --lib -- vendor::pnpm: 201 passed, re-run on eb4ddc6.
• Pinned-matrix leg pnpm_pinned_matrix_vendored_lifecycle_and_manifestless_vex with SOCKET_PATCH_PNPM_E2E_VERSION=10.28.0: ok.
• Wrapper tests: not touched (no npm/, pypi/ or gem/ changes are needed).

CI on eb4ddc6: all 8 Actions workflows that run for these paths passed (CI, pnpm, npm, Bun, vlt, Composer, Benchmarks, Audit GHA Workflows), and Bugbot found no issues.

Generated by Claude Code