GeezerVison

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

Fixes #935

Root cause

#1469 fixed the hosted half of #935. A hosted pnpm scan now warns redirect_copy_unpatched when the same pnpm-lock.yaml also installs a file: directory or tarball copy of the pinned name@version. The vendored pnpm backend (crates/socket-patch-core/src/vendor/pnpm_lock.rs) had no matching check. It writes overrides: {name@version: file:.socket/vendor/…}, which pnpm applies only to the registry edge, and reported success with warnings: [] while the file: copy kept installing unpatched. vex was already honest about it (it declines with patched_ref_unattributable), so the missing piece was the scan-time warning. Yarn berry's vendored backend already warns vendor_copy_unpatched for the same shape (#939).

Changes

• vex::discover::npm::pnpm_lock_file_copies: the file: directory and tarball copies of one name@version in a pnpm lock. It classifies entries the way pnpm_entry_ref does and reads them through discovery's own record_pnpm_file_copies: a directory's version comes from its package.json through the guarded reads, and a tarball's version from the lock's version: field. Vendoring and vex therefore agree on which copies count. Copies whose name or version already rules them out are dropped before any read.
• Vendored pnpm preflight, both lock dialects: each such copy is named with a vendor_copy_unpatched warning (entry key, source, and the "depend on the registry release" remedy). The registry copy is still vendored. The warning shows in dry runs too. The lock is re-parsed only when a v9 key names the package (name@file:) or, for legacy locks, any non-vendor file: line exists.
• CLI_CONTRACT.md (vendor_copy_unpatched row) and docs/ecosystems.md (pnpm hosted/vendored notes) now cover pnpm.

Tests (red → green)

To show red, I disabled only the new preflight block and re-ran:

• vendor::pnpm_lock::tests::file_copy_of_the_vendored_release_is_named (v9 workspace lock; directory copy, tarball copy; negatives: another version's directory or tarball, an unreadable directory; dry run and real run). Red without the fix: directory dry_run=true: []. Green with it.
• vendor::pnpm_lock_legacy::tests::file_copy_of_the_vendored_release_is_named (lockfileVersion 6.0, legacy file:forks/left-pad key whose name comes from name:; a copy of another version is not named). Green.
• Real pnpm: e2e_vendor_pnpm_build::pnpm_vendor_names_a_file_copy_of_the_vendored_release. This is the issue's workspace repro: member a on registry [email protected], member b on file:../../forks/left-pad, vendor --json, then a fresh --frozen-lockfile install from an empty store. With pnpm 10.28.0 and SOCKET_PATCH_PNPM_E2E_REQUIRED=1: red without the fix (exactly one event names the copy; the envelope had no such event), green with it. a installs the vendored bytes and b keeps the fork, as the warning says.

Per issue:

• Warn during pnpm scans when non-registry copies cannot be patched #935 vendored scan names the file: directory copy: all three tests above.
• Warn during pnpm scans when non-registry copies cannot be patched #935 vendored scan names the file: tarball copy: v9 unit test.
• Warn during pnpm scans when non-registry copies cannot be patched #935 hosted scan and vex: already fixed on main by Fix silent hosted pnpm pin beside a file: copy #1469 (in_process_redirect_pnpm Warn during pnpm scans when non-registry copies cannot be patched #935 tests still pass).

Local gates

• cargo fmt --all -- --check: clean.
• cargo clippy --workspace --all-features -- -D warnings: clean. (--all-targets fails on lints in unrelated test files such as crawler_ruby_e2e; none are in files this PR touches.)
• cargo test -p socket-patch-core --all-features --lib: 6791 passed, 4 failed. All 4 are chmod/unremovable-file tests that can't fail as root (copy_tree::relax_loop_must_not_traverse_symlinked_root, vlt_heal::an_unremovable_hidden_lock_keeps_every_store_entry, pypi_poetry::wire_write_failure_…, pypi_requirements::wire_failure_…). Fix berry unwind under a user yarn patch (#962) #1733 and Fix hosted cargo pins for multi-line inline tables (#757) #1735 list the same four; none touch this diff. After the review commit: pnpm_lock modules 268/268, vex::discover 423/423.
• CLI: e2e_vendor_pnpm_build 40 passed (I skipped the three two_document legs: they pin packageManager: pnpm@11/12, which this sandbox's proxy can't fetch, and one hung on it), and the other pnpm CLI suite run 39/39.
• I didn't run the full cargo test --workspace: building every CLI test binary has run these containers out of disk before. CI runs it.
• No wrapper changes (npm/, pypi/, gem/ only dispatch the binary).

CI

All checks are green on 481393b (37 success, the rest skipped). Cursor Bugbot found no issues on 481393b. The PDM VEX leg went red on 515deee because of unearth 0.19.0, published to PyPI today. The fix is #1738, and its commit is ported here as 481393b (it becomes a no-op once #1738 lands).

/code-review high

Fixed in 515deee:

• per-package re-parse of the whole lock: now only when the lock has a name@file: key (v9);
• every file: copy's manifest read before filtering: now filtered by known name/version first;
• no legacy-dialect coverage: legacy test added.

Not fixed, and why:

• A file: directory outside the project root (file:../sibling-repo/left-pad) is not read, so it is not named. Discovery's guarded reads never leave the root, and hosted mode and vex behave the same today. Widening that is a policy change for all three, not this fix. A tarball outside the root is still named, from the lock's version: field.
• When the release is installed only from a file: copy, vendoring still refuses with vendor_lock_entry_not_found and its pnpm install remedy, which can't help. That's a separate refusal path (yarn berry has a dedicated message for it). It's a good follow-up but outside Warn during pnpm scans when non-registry copies cannot be patched #935's "warn beside a wired registry entry".
• The entry classification sits next to pnpm_entry_ref rather than being extracted from it. pnpm_entry_ref interleaves ref, diagnostic and copy handling. The copy reading itself (record_pnpm_file_copies) is shared, and a shared reader means a drift would show in the e2e (vex vs warning).
• .socket/vendor/ literal in the quick prefilter: it only decides whether to parse. A stale literal costs a parse, never a wrong warning.

Generated by Claude Code