GeezerVison

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

Fixes #1561

Summary

A yarn berry portal: / link: dependency under another name ("lp2": "portal:./vend/lp") whose relative target can't be read is now treated as an unknown copy of any version of any package, the same as an absolute one (#1540). Hosted warns redirect_copy_unpatched, vendored warns vendor_copy_unpatched, and vex withholds every package that lock wires. Before this change the copy was dropped: scans reported success and VEX attested not_affected, while the install with the target present linked unpatched bytes as node_modules/lp2.

Root cause

Such a copy's lock version is the placeholder 0.0.0-use.local, so only its package.json says what it is. When reading that manifest yielded no identity, both the vendored/hosted copy finder (vendor/yarn_copies.rs other_name_copies) and VEX lockfile discovery (vex/discover/yarn.rs record_copies) treated "the read failed" the same as "read and found to hold no versioned package" (a link: to plain assets), and skipped the copy unless the path was absolute.

Fix

One shared predicate, yarn_copies::linked_copy_unknown, used by both callers. A linked copy is unknown when it is:

• never read (an absolute path, Yarn berry renamed-copy detection ignores a portal: / link: copy with an absolute path, so hosted and vendored scans succeed and every VEX path attests not_affected while that copy installs unpatched #1540),
• a missing target directory,
• an empty target directory (what git leaves for a submodule CI never checked out, the issue's main real-world trigger),
• a package.json that isn't a readable regular file, or isn't JSON (a Git LFS pointer, an encrypted blob).

It is not a package copy, and so stays ignored per the #1551 review intent, only when it is a non-empty directory with no package.json, or a parsed manifest naming no versioned package. CopyRef::is_unread_linked is folded into the predicate. The berry vendored warning keeps the "installs a package" wording for every unidentified linked copy. docs/ecosystems.md now spells out the missing / empty / LFS cases.

Tests (red → green)

The first commit (87d9321) holds only the tests, which failed on main as listed. The empty / lfs-pointer variants came from the pre-ready /code-review high pass.

Commands run locally (Linux, as root):

• cargo fmt --all -- --check: ok
• cargo clippy --workspace --all-features -- -D warnings: ok
• cargo test --workspace --all-features --no-fail-fast: 14,563 passed. The 10 failures are environment-only and touch no yarn code: write-failure / read-only-parent tests that can't fail when run as root (e.g. copy_tree::relax_loop_must_not_traverse_symlinked_root, pypi_requirements::wire_failure_rolls_back_already_written_files, repair_*, redirect_json_mode_write_failures_emit_error_envelope), and e2e_bun_lockb::binary_shared_bundled_record_hosted_pin_is_managed, which needs the live patch API (sandbox tunnel blocked). CI runs non-root with network.
• yarn-berry e2e with real yarn 4.18.0 (SOCKET_PATCH_YARN_E2E_REQUIRED=1): e2e_redirect_yarn_berry_build 37/37, e2e_vendor_yarn_berry_build 44/44, e2e_yarn4_pnpm_linker_build 40/40, e2e_yarn4_workspaces_build 39/39.
• Wrappers (npm/, pypi/, gem/) only dispatch to the binary and need no change.

/code-review high: findings not fixed

• Hosted in-memory scans and target files the host never sent. In memory mode, a relative linked copy is read only when the host includes its target's package.json in the snapshot (the new control test shows such a file is read and honoured). When the host leaves it out, the copy is now flagged as possibly unpatched instead of silently dropped. Dropping it was the fail-open this issue reports. Flagging matches how memory mode already treats an unread file: directory copy at its lock 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). Teaching path selection to fetch linked targets' manifests would mean parsing yarn.lock before the fetch, which is a separate change. Follow-up if wanted.
• other_name_copies probes with ProjectView::Disk (sync is_dir) rather than group-commit-aware helpers. The read beside it uses read_regular_to_bytes on the same disk path. No caller runs this inside an open group commit before the lock rewrite, and one stat per linked candidate is negligible. Left as is.

🤖 Generated with Claude Code

Generated by Claude Code