GeezerVison

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

Fixes #1494

Summary

When run from inside a vlt, pnpm or npm-linked workspace member, apply reported the member's npm alias dependency ("lp": "npm:[email protected]") as package_not_installed and exited 1. rollback couldn't restore that dependency either, even though scan had offered the patch through the same link. Both commands now patch and restore it.

Root cause

From a member directory, the npm resolver's only root is the member's own node_modules. Under a root-store layout the alias entry packages/a/node_modules/lp is just a symlink into the root store. The resolver's direct probe looks for node_modules/left-pad, and its alias pass skips links on purpose (#856), so no copy was found. #1470 had already closed the same gap for path-scoped matching only (find_package_paths_for_path_scope + npm_links_to).

Fix (crates/socket-patch-cli/src/ecosystem_dispatch.rs)

• The root-link pass moves into a shared dispatch_find_with_npm_links. It is now used by path scoping (every link, as before) and by the copy lookups: find_all_packages_for_purls (apply), find_all_packages_for_rollback[_reusing] (rollback) and find_packages_for_rollback_reusing (get, vendor).
• find_manifest_package_copies_reusing (apply --check, vex) gets the same unresolved-only pass (Bugbot finding: run from the member, --check reported the patched copy as package_not_installed). Two vex_consumed tests whose setup assumed the resolver never returns a link now check that it returns the same copies as the identity fallback.
• The copy lookups use links only for purls that have no resolved copy (NpmLinks::ForUnresolved). The pre-ready /code-review high showed why this matters: when the resolver has already found a copy, the apply engine's store fan-out reaches every peer variant of it. Taking a member link to another variant on top of that visited it twice and brought back Agent-mode apply in a pnpm workspace reports each member-linked package twice, inflating the --json skipped count with duplicate already_patched events #633's phantom already_patched / already-original event. Restricting the pass also keeps a first-party file: alias link next to a patched registry copy from turning a clean run into a refusal. And the pass is skipped entirely when every purl resolves, so the common case pays nothing extra.
• Nothing changes in the npm, PyPI or gem wrappers: they only dispatch to the binary.

Test evidence

I also reproduced the issue with real pnpm 10.28: a workspace with packages/a depending on "lp": "npm:[email protected]" and a hand-staged manifest. Run from packages/a with the fixed binary, apply --offline exits 0 with applied, and the root store's left-pad/index.js is patched (require.resolve('lp') resolves to it). rollback then gives success with rolledBack: 1 and restores the bytes.

Local runs:

• cargo fmt --all -- --check: clean
• cargo clippy --workspace --all-features -- -D warnings: clean
• cargo test -p socket-patch-core -p socket-patch-cli --all-features --lib --test apply --test rollback --test scan --test get --test in_process_vendor --test cli: every CLI target passes (920 lib, 135 apply, 111 rollback, 87, 133, 59, 131). 4 socket-patch-core lib tests fail locally because they rely on read-only permissions and this sandbox runs as root (e.g. copy_tree::relax_loop_must_not_traverse_symlinked_root: "removal cannot succeed under a read-only parent"). This PR doesn't touch core, so CI is the check there.
• A full cargo test --workspace ran out of this sandbox's disk allowance while linking test binaries, so I ran the targeted suites above instead. CI covers the rest.

Review findings not fixed

• "get_node_modules_paths errors are swallowed and the walk is retried": this was already the behavior in path scoping, and NpmCrawler::get_node_modules_paths always returns Ok, so there's no real failure path.

🤖 Generated with Claude Code

https://claude.ai/code/session_0195pcxXZ2GXtByX1L8egMhJ

Generated by Claude Code