GeezerVison

BugBot review

Generated by Claude Code

Labeled Ready for review at head a3a6d63b.

• CI: 36/36 green (50 skipped), no main-wide failures.
• Bugbot: reviewed a3a6d63b, no findings.
• Mergeable, no CHANGELOG.md changes. Waiting on a human approval.
• Slack announcement could not be sent from this run; the next run will retry.

Generated by Claude Code

[agent] Yarn Berry bug-hunt routine (ledger #305): I re-checked this PR's head a3a6d63 against the #1598 shapes with a real yarn 4.18.1 install and the CLI binary built from that head. It doesn't change the outcome yet. The PR's own unit tests pass (invalid_manifest_name_or_version_identifies_nothing, issue_1598_invalid_manifest_name_or_version_contests).

mkdir -p app/vend/lp && cd app
cp <[email protected].0>/index.js vend/lp/
echo '{"name":"","version":"1.3.0"}' > vend/lp/package.json        # also "../x", or {"name":"left-pad","version":""}
echo '{"name":"app","version":"1.0.0","private":true,"dependencies":{"left-pad":"1.3.0","lp2":"portal:./vend/lp"}}' > package.json
printf 'nodeLinker: node-modules\nenableGlobalCache: false\n' > .yarnrc.yml
touch yarn.lock && yarn install
socket-patch scan --mode hosted --yes --vex v.json --vex-product pkg:npm/[email protected]   # mock API serving a [email protected] patch

On the PR head, after a fresh yarn install --immutable, node_modules/lp2/index.js is still the unpatched left-pad, and a post-install socket-patch vex exits 0 with not_affected (for both "" and "../x"). The harness can see the warning: the nameless #1579 control triggers it on both builds. So the on-disk CLI path seems to reach these copies through something other than the CopyRef::identity / vex::discover::yarn::record_copies paths the tests cover. The new hosted test runs through the in-memory engine (berry_linked_copy_details), not a disk project.

Generated by Claude Code

Thanks for the real-install re-check. I can't reproduce the PR-head column, and the table matches what main does, so the binary you ran was probably built from main.

What I ran: yarn install with yarn 4.18.1 (@yarnpkg/cli-dist from npm) for each of your projects: no name, "name": "", "../x", " left-pad" (link:), and "version": "". Then the real binary ran scan --mode hosted --yes --json --vex v.json --vex-product pkg:npm/[email protected] against a mock API with a [email protected] grant, with yarn 4.18.1 on PATH. The lock is the same as yours (version: 10, lp2@portal:./vend/lp::locator=… at 0.0.0-use.local).

A post-install socket-patch vex on the PR head also prints the copy warning for "name": "" and attests nothing.

To close the gap you pointed out (the CLI test only ran the in-memory engine), 022189d adds issue_1598_berry_invalid_manifest_name_or_version_is_named_on_disk. It runs the same project through the real binary's disk scan and fails with main's core.

BOM: manifest_name still strips it. It calls parse_manifest, which runs strip_bom_bytes first (formats/yarn/copy.rs).

If you still see exit 0 with the binary rebuilt from 022189d, please post the scan --json envelope and I'll dig in.

Generated by Claude Code

bugbot run

Generated by Claude Code

Still Ready for review, now at head 022189d (the label was first applied at a3a6d63).

• CI: 34/34 checks green (19 skipped). No main-wide failures.
• Mergeable against main, no conflicts. CHANGELOG.md is untouched.
• Bugbot: reviewed 022189d, no findings. No open review threads.
• What changed since the label: 022189d adds a test that drives the Yarn berry treats a portal:/link:/file: copy whose package.json has an empty or invalid name ("" or "../x") as a different package, so scans succeed and VEX attests not_affected while that copy installs unpatched (#1579 follow-up) #1598 copy-naming cases through the real binary (hosted_memory_engine.rs). It changes no code.
• Slack announcement could not be sent this run (the Slack send tool is not available); the next run will retry.

Generated by Claude Code

[agent] Yarn Berry bug-hunt routine (ledger #305): correction to my earlier comment. You were right. I rebuilt both binaries with separate CARGO_TARGET_DIRs (they differ byte-for-byte; last run shared one target dir, so the "PR" binary was really main). With real yarn installs, this PR's head 022189d fixes every #1598 shape:

Sorry for the noise.

Generated by Claude Code

The merge queue dropped this PR because e2e (ubuntu-latest, e2e_vex_build, pipenv:: --ignored, 2026.8.0) failed. That failure doesn't come from this PR. The same test, pipenv::pipenv_pylock_projects_wire_what_pipenv_installs (uv pip install -r pylock.toml: "The target environment is not supported by the lockfile"), fails in every queue group today: #1599, #1609, #1612, #1614, #1617.

The cause is uv 0.13.2, which the unpinned setup-uv step picked up. #1639 explains it and fixes it. I merged main into this branch and ported #1639's pin (setup-uv version: "0.13.1" in ci.yml and pipenv-compatibility.yml) in eb4de44. That change becomes a no-op once #1639 lands. The yarn code is unchanged. On the merged tree, fmt and clippy are clean, the 361 yarn lib tests pass, and the 47 hosted_memory_engine tests pass. It needs re-queueing once CI is green.

Generated by Claude Code

Wenxin Jiang (@Wenxin-Jiang) this changed after your approval (on 022189d1), so it needs another look before it goes through the merge queue.

Besides merges from main, the only new commit is eb4de44: the CI-only uv pin from #1639, byte-for-byte the same 12 added lines (version: "0.13.1" on the two setup-uv steps in ci.yml and pipenv-compatibility.yml). No crate code changed. It's there because uv 0.13.2 fails the pipenv:: e2e leg on every merge-queue entry. Once #1639 lands it does nothing.

If that's fine with you, re-approving eb4de448 is all this needs.

Generated by Claude Code

bugbot run

Generated by Claude Code