Fix yarn berry absolute portal:/link: copies (#1540)

[Mikola Lysenko (mikolalysenko)]

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

Fixes #1540

Summary

A yarn berry portal: or link: dependency with an absolute path ("lp2": "portal:/home/me/shared/left-pad") links a directory into node_modules/lp2, and socket-patch can't see what that directory holds. Before this PR, hosted and vendored scans reported success with no copy warning, and every VEX path (in-run, lock-only, post-install) attested not_affected while that copy installed unpatched. Now:

• Hosted scans still pin the registry entry and warn redirect_copy_unpatched naming the entry.
• Vendored scans still wire the registry entry and warn vendor_copy_unpatched.
• vex attests nothing that yarn.lock wires while the copy is there. This is the same fail-closed rule an unread file: copy already gets at its own version (Yarn classic renamed-copy detection (#1489) misses a file: copy outside the project root and a tarball whose root isn't package/, so scans succeed and VEX attests while that copy installs unpatched #1516).

Root cause

A lock is untrusted input, so an absolute copy path is deliberately never read (CopyRef::read_path, #1516). An unread file: copy is kept as an unidentified copy at its lock version. A portal: / link: copy has no lock version (yarn records 0.0.0-use.local), so an unread one was dropped in both lockfile discovery (vex/discover/yarn.rs::record_copies) and the vendored backends (vendor/yarn_copies.rs::other_name_copies).

Fix

• UnidentifiedCopy.version is now Option<String>. None means any version, and the copy is expanded against every ref its lock wires.
• CopyRef::is_unread_linked marks a never-read portal: / link: copy. Discovery records it as an unidentified copy of any version. The vendored backend names it (unidentified wording, no made-up version) and never takes it as proof the package is installed.
• Deliberately unchanged: a relative portal: / link: that is read and holds no versioned package (for example link:./assets, a plain directory, which link: allows) is still left alone. That way it doesn't block VEX for the whole lock. A control test pins this.
• berry_copy_ref now cuts only the ::locator= bindings and the # selector, not every :. A Windows drive path (portal:C:/Users/me/lp) was being parsed as the relative path C.
• docs/ecosystems.md documents the absolute-path behavior and points to using a relative path.

Tests (red → green)

Issue	Test	Without fix	With fix
#1540 discovery / VEX	vex::discover::yarn::tests::issue_1540_absolute_portal_and_link_copies_contest_every_ref	FAIL (ref attested)	pass
#1540 vendored	vendor::yarn_berry_lock::tests::issue_1540_absolute_portal_and_link_copies_are_named	FAIL (0 warnings)	pass
#1540 hosted (CLI)	hosted_memory_engine::issue_1540_berry_absolute_portal_and_link_copies_are_named	FAIL (0 redirect_copy_unpatched)	pass
control	issue_1540_relative_link_to_a_plain_directory_contests_nothing, absolute_linked_refs_keep_the_path_and_are_unread	n/a	pass

Local runs:

• cargo fmt --all -- --check: clean
• cargo clippy --workspace --all-features -- -D warnings: clean
• cargo test --workspace --all-features --no-fail-fast: every yarn, vex and hosted suite passes. 10 tests fail only in this sandbox and are untouched by this diff:
  • 9 write-failure-injection tests that rely on read-only permissions, which root bypasses (copy_tree, vlt_heal, pypi_poetry, pypi_requirements, repair, redirect write-failure).
  • 1 e2e_bun_lockb test that reaches the live patches-api.socket.dev, which the sandbox proxy blocks.
• No wrapper (npm/, pypi/, gem/) changes are needed. This is core discovery logic only.

Review notes

/code-review high was run. Fixed:

• The any-version rule was limited to never-read copies.
• The vendored warning wording no longer names a made-up version.
• The Windows drive path is parsed correctly.
• The doc comment was updated and the expansion simplified.

Not fixed:

• Vendored warning per package. Vendoring N packages beside one absolute portal copy emits one vendor_copy_unpatched per package. Each warning is accurate for its package, and the per-package plans don't share state. The hosted path already de-duplicates by entry.
• UnidentifiedCopy.version type change. The field's type changes on a pub struct, but Discovery::unidentified_copies is always empty once discovery returns, and nothing outside the crate reads it.

🤖 Generated with Claude Code

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[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 7a3fb87. Configure here.}

[Mikola Lysenko (mikolalysenko)]

Labeled Ready for review at head 7a3fb87.

• CI: 86/86 checks green (36 success, 50 skipped), no main-wide failures.
• Bugbot: reviewed 7a3fb87, no new issues; no unresolved review threads.
• Already approved by Tanmay Singla (@Tanmay182003) on this head. No CHANGELOG.md change.
• Reviewer focus: the fail-closed VEX rule for unread absolute portal:/link: copies (no lock version, so any wired version is withheld).

---

Generated by Claude Code