Skip orphaned pnpm store entries in vendored scan (#1197)

[Mikola Lysenko (mikolalysenko)]

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

Fixes #1197

Summary

pnpm 7–11 keep a removed or upgraded-away package's node_modules/.pnpm/<name>@<version> entry for up to 7 days (modules-cache-max-age). pnpm 12 keeps an upgraded-away one until pnpm prune. Nothing links to the entry and neither lock lists it. The npm crawler still walked it, so scan --mode vendored requested its patch and failed it with vendor_lock_entry_not_found (partial_failure, exit 1) on every run. The pnpm install remedy it printed doesn't remove the entry.

The scan now skips these orphans. It reads pnpm's current lockfile, the lock.yaml that pnpm rewrites in its virtual store on every install, and drops an in-project (or relocated) .pnpm entry whose package that file no longer lists:

• formats::pnpm::InstalledPackages reads the current lockfile in every generation: v5.4 /name/1.0.0, v6 /name@1.0.0, v9 name@1.0.0 keys, peer suffixes stripped, and file: / url / git entries by their name: / version: fields or the v9 key name. An entry with no version counts as "any version installed". If any entry can't be named, the result is None and nothing is dropped.
• orphaned_pnpm_store_entry_sync names the entry, either from a registry name@version dir or a name@file+… tarball dir, and confirms it against the entry's package.json. It drops the entry only when that (name, version) is not installed. An entry it can't name or read is kept.
• This applies only on the scan's live_only path, as for Bun's orphans (With Bun's isolated linker, vex refuses every hosted patch as not_applied after the usual in-place bun install, because it checks orphaned node_modules/.bun registry entries that Bun never removes (regression from #496) #599). The resolver and peer-variant finder (rollback, remove) still reach orphans.

Measured on real pnpm 7.33.7, 8.15.9, 10.34.6, 11.28.5 and 12.10.1 with pnpm add -E left-pad@1.2.0 over 1.3.0: the left-pad@1.3.0 dir stays in every version, and lock.yaml lists only left-pad@1.2.0, with the key shapes above. That covers the pnpm 12 upgrade path from the follow-up comment.

• CI follow-up (1e99006): the first push slowed the pnpm scan benchmarks by about a third (3000 packages). It read every entry's package.json before checking the lock, and it ran the full entry grammar over every lock entry. A live registry entry now needs no read, and the lock is read in one line walk. A current lockfile that lists no packages, such as a stub or a project with no dependencies left, now drops nothing. This also fixes crawler_npm_e2e::crawl_all_inventories_pnpm_virtual_store_exactly_once, whose fixture has a stub lock.yaml.

Root cause

list_pnpm_shaped_store_entries_sync enumerated every .pnpm entry with no reachability filter. Its live_only mode filtered only Bun stores, on the assumption that pnpm prunes on install, which pnpm doesn't do.

Tests (red → green)

Issue	Test
#1197 CLI	scan_vendor_e2e::exact_download_plan::vendored_scan_skips_a_pnpm_store_entry_the_install_dropped: a purl-aware batch mock and an orphaned .pnpm/pkg-y@1.0.0. Without the crawler change it fails with scannedPackages: 2, partial_failure, exit 1. With the change it exits 0, success
#1197 crawler	npm_crawler::tests::test_pnpm_store_entries_the_current_lockfile_drops_are_not_scanned covers a removed entry, an upgraded-away entry, an old vendored name@file+… entry, a live scoped vendored entry, v5.4/v6/v9 keys, the no-lock.yaml control and rollback reach. It failed before the fix
reader	formats::pnpm::tests::installed_packages_read_every_lock_generation

Commands run

• cargo fmt --all -- --check, cargo clippy --workspace --all-features -- -D warnings: clean
• cargo test -p socket-patch-core --lib: 6111 passed
• --test scan_vendor_e2e, e2e_vendor_pnpm_build, scan_pnpm_relocated_store_cwd_e2e, in_process_vendor_pnpm_takeover, in_process_vendor_pnpm_parent_child, e2e_redirect_pnpm_build, e2e_yarn4_pnpm_linker_build: all pass

Docs: docs/ecosystems.md (crawl section).

🤖 Generated with Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 4a80b72. Configure here.}