GeezerVison

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

Fixes #1082

Summary

A yarn berry hosted pin routes each descriptor that existed at scan time to the Socket tarball through a root resolutions selector. Sometimes a range of the same package is added later, such as a workspace member's left-pad: 1.3.0, or an npm: alias of it. Yarn then locks that descriptor as a separate registry entry, and that copy installs unpatched.

Before this PR:

• A re-scan refused with redirect_yarn_berry_ambiguous_entry and suggested "run yarn install to dedupe". That can't work, because the pin is what keeps the two entries apart.
• rollback / remove exited 0 but left two entries with the same resolution:. Yarn merges such entries, so every fresh yarn install --immutable failed with YN0028.
• The vendored counterpart had the same two-entry result: vendor --revert, rollback or remove after an alias was added post-vendoring.

After this PR:

• The re-scan adds a selector for the new range and folds its registry entry into the pinned one.
• The hosted restore and the vendored revert merge the restored entry into the entry yarn wrote for the same resolution. The result is one entry, keyed by every descriptor in sorted order, with yarn's own body.

Root cause

The berry hosted rewriter and both unwind paths treated the hosted (or vendored) entry and a later registry entry of the same name@version as unrelated blocks:

• patch/redirect/mod.rs (berry rewriter): when targets.len() > 1, it refused, even when one target was our own URL-keyed entry and the others were plain npm: registry entries.
• patch/redirect/upstream/npm.rs (restore_berry) and vendor/yarn_berry_lock.rs (revert_yarn_berry_opts): both restored the original entry next to an existing entry with the same resolution.

The bisect in the issue points at #1008. Its Discovery::shadowed change hands these refs to rollback; before it, they were refused.

Changes

• Re-scan fold (redirect/mod.rs): when exactly one target is URL-keyed, the other npm: targets are folded in. BerryResolutionsPin::add_ranges routes their ranges (plus any matching catalog selectors) and removes their entries (edit kind redirect_yarn_berry_entry_folded). Two registry entries with no pin of ours still get ambiguous_entry.
• Shared merge (formats/yarn/stanzas.rs, merge_same_resolution): folds each restored stanza into a sibling with the same resolution:. The merged stanza keeps the sibling's (yarn-written) body and takes the sorted union of both keys. The merged key goes to render, which places it in yarn's order.
• Hosted restore (upstream/npm.rs): runs the merge after re-keying. The yarn_berry_node_gyp_unresolved advisory is dropped for an entry that was merged into yarn's own.
• Vendored revert (yarn_berry_lock.rs): runs the merge over the restored lock and pruned entries.
• docs/ecosystems.md: documents the fold and the merge.

Tests (red on main, green here)

Per-issue checklist:

• Yarn berry hosted pin can't cover a descriptor added after pinning: re-scan refuses with an impossible "dedupe" remedy, and rollback reports success but leaves a lock every yarn install --immutable rejects (YN0028) #1082 point 1 (re-scan dead end): fold test and real-yarn e2e
• Yarn berry hosted pin can't cover a descriptor added after pinning: re-scan refuses with an impossible "dedupe" remedy, and rollback reports success but leaves a lock every yarn install --immutable rejects (YN0028) #1082 point 2 (rollback/remove → YN0028): in-process test and real-yarn e2e (--immutable passes after rollback)
• Yarn berry hosted pin can't cover a descriptor added after pinning: re-scan refuses with an impossible "dedupe" remedy, and rollback reports success but leaves a lock every yarn install --immutable rejects (YN0028) #1082 vendored counterpart (comment of 2026-10-09): vendored revert test
• Point 3 (VEX) was already fixed by Stop VEX attesting over yarn PnP, pnpm bundled and deno.lock copies #1033.

Local runs:

• cargo fmt --all -- --check: clean
• cargo clippy --workspace --all-features -- -D warnings: clean
• cargo test --workspace --all-features --no-fail-fast (with corepack yarn available): 13905 passed, 15 failed. None of the failures is in code this PR changes, and all come from the sandbox:
  • 12 rely on chmod-based write failures, which the sandbox's root user bypasses (*_write_failure_*, *unremovable*, relax_loop_must_not_traverse_symlinked_root, and similar).
  • 1 is e2e_bun_lockb::binary_shared_bundled_record_hosted_pin_is_managed, which needs patches-api.socket.dev.
  • 2 are mode_migration_npm::berry_{hosted_then_vendored,vendored_then_hosted}_takeover_*. They panic in their own fixture setup (mount_hosted_mocks, mode_migration_npm.rs:329), where the test's reqwest client can't verify the sandbox proxy's certificate for registry.npmjs.org. That happens before any socket-patch code runs. Earlier agent runs had no corepack yarn, so these skipped there.
• cargo test -p socket-patch-cli --test e2e_yarn4_workspaces_build with real yarn 4.12.0 (SOCKET_PATCH_YARN_E2E_REQUIRED=1): passed

/code-review high

Fixed:

• pruned entries now merge too
• the node-gyp advisory is no longer kept for a merged-away entry
• the catalog lookup is skipped when nothing is folded
• stale moved keys are dropped

Not changed:

• Folding with no earlier pin. Several npm: entries of one version with no URL entry means they have different locators, for example a plain locator and an ::__archiveUrl= one. Yarn does not merge those, so the refusal stays.
• A retried vendored revert after a partial failure. If the package.json write fails after the lock was merged, a retry reports vendor_lock_entry_removed (a not-drift warning, After yarn remove of a vendored package, rollback fails forever (exit 1) and no command can clean up the orphaned yarn classic artifact; the remedies it prints don't work #665) instead of staying silent. The retry still completes the revert.
• O(restored × entries) merge scan. The restored count is the number of pins in one unwind, so the simple scan is enough.

🤖 Generated with Claude Code

https://claude.ai/code/session_01TY1qeZG6YhbTSVfdgf4hhG

Generated by Claude Code