GeezerVison

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

Fixes #632

Summary

scan --mode hosted now pins yarn berry dependencies declared through a yarn catalog ("left-pad": "catalog:"). Before this, the scan reported redirected: 1, but the next yarn install --immutable failed with YN0028 and a plain yarn install silently installed the unpatched release. This was a regression from #465.

Root cause

Since #465 the hosted yarn berry pin routes the lock entry's descriptors to the hosted tarball through root package.json resolutions, keyed name@npm:<range>. Those keys come from the lock key's expanded ranges in berry_resolutions_pin. Yarn matches resolutions against the manifest descriptor before it expands the catalog, so left-pad@npm:^1.3.0 never matches a dependency declared catalog: or catalog:<named>.

Fix

• berry_resolutions_pin reads the .yarnrc.yml catalog: / catalogs: tables through the new berry_catalog_selectors (serde-saphyr). Some catalogs give the package a range that, normalized to yarn's npm: form, is one of the pinned ranges. For each of those, the pin also routes name@catalog: or name@catalog:<named> to the hosted tarball.
• The catalog tables are read as string tables, so an unquoted range keeps its exact text (1.10 stays 1.10), the way yarn's failsafe schema reads .yarnrc.yml.
• The npm: selectors stay: transitive dependents still ask for the expanded range, and rollback rebuilds the lock key from them.
• Catalog selectors are derived from the final selector list. So a re-run over a pin written before this fix (lock already keyed by URL, only the npm: selector) adds the missing catalog selector and leaves the lock alone.
• Rollback needs no change. It already drops every selector routed to the hosted URL and rebuilds the lock key from the npm: ones; a new test covers this.
• A user-authored name@catalog: resolution still refuses with redirect_yarn_berry_resolutions_conflict.
• docs/ecosystems.md: the yarn berry hosted notes now describe catalog pins.
• The npm, PyPI and gem wrappers only dispatch to the binary, so they need no change.

Checked by hand with real yarn 4.12.0:

• {"left-pad@npm:^1.3.0": X, "left-pad@catalog:": X} installs the patched bytes for a catalog: dependency, and --immutable passes.
• On a project that defines the catalog but declares a plain range, the unused catalog: selector is harmless: the install gets the patched bytes and --immutable passes.

Per-issue checklist

• Hosted yarn berry pin of a catalog: dependency keys resolutions by the resolved npm: range, so every yarn install --immutable fails YN0028 (regression from #465) #632, default catalog: yarn_berry_pin_routes_a_default_catalog_dependency (LF, and BOM + CRLF .yarnrc.yml, quoted npm: value)
• Hosted yarn berry pin of a catalog: dependency keys resolutions by the resolved npm: range, so every yarn install --immutable fails YN0028 (regression from #465) #632, workspace with default + named catalog in one merged entry: yarn_berry_pin_routes_every_catalog_locking_the_entry. Catalogs with another range, another package, or a patch: protocol are ignored.
• Hosted yarn berry pin of a catalog: dependency keys resolutions by the resolved npm: range, so every yarn install --immutable fails YN0028 (regression from #465) #632, unquoted numeric ranges: yarn_berry_catalog_ranges_keep_their_source_text. 1.10 matches npm:1.10, not npm:1.1. Integer ranges, null entries, other nested keys, a non-table catalog and invalid YAML are all handled.
• Hosted yarn berry pin of a catalog: dependency keys resolutions by the resolved npm: range, so every yarn install --immutable fails YN0028 (regression from #465) #632, re-run loop: yarn_berry_catalog_pin_rerun_is_stable_and_heals_an_old_pin. A re-run is a no-op, and a pin written before this fix gets healed.
• Hosted yarn berry pin of a catalog: dependency keys resolutions by the resolved npm: range, so every yarn install --immutable fails YN0028 (regression from #465) #632, rollback: in_process_redirect::yarn_berry_catalog_dependency_is_pinned_and_rolled_back. package.json comes back byte-identical, and the lock gets its npm: key back.
• Hosted yarn berry pin of a catalog: dependency keys resolutions by the resolved npm: range, so every yarn install --immutable fails YN0028 (regression from #465) #632, real install: e2e_redirect_yarn_berry_build::berry_redirect_catalog_dependency_fresh_checkout_installs (real yarn 4.12.0). A fresh yarn install --immutable --check-cache installs the patched bytes. On yarn < 4.10 the test prints a note and returns, because catalogs don't exist there.

Test evidence

• Red to green: with the catalog lookup disabled, the new core tests fail, and so does the real-yarn e2e (no left-pad@catalog: selector). With the fix, all pass: cargo test -p socket-patch-core --lib -- yarn_berry gives 102 passed on 9abb2d9.
• cargo test -p socket-patch-cli --test in_process_redirect -- yarn_berry: 7 passed.
• SOCKET_PATCH_YARN_E2E_REQUIRED=1 cargo test -p socket-patch-cli --test e2e_redirect_yarn_berry_build: 15 passed against real yarn 4.12.0.
• cargo test -p socket-patch-cli --lib: 840 passed on 454b068.
• New code is rustfmt-formatted (cargo fmt --all -- --check also flags pre-existing code on main). cargo clippy --workspace --all-features -- -D warnings is clean.
• An earlier full local cargo test --workspace --all-features --no-fail-fast run had 14 failures, all from the sandbox. 12 were chmod-based write-failure tests, which can't fail when running as root. 2 were mode_migration_npm fixtures whose registry download rejects the sandbox proxy's TLS certificate. CI runs these for real.

History

• 55dc0cb backed out unrelated rustfmt churn. cargo fmt --all had reformatted files this PR doesn't touch. CI on 55dc0cb was green, and it was approved.
• 2ab819a merged main.
• 9abb2d9 fixes a Bugbot finding: berry_catalog_selectors used to read unquoted catalog ranges as numbers, so 1.10 became 1.1. It now deserializes the catalog tables as string tables. Bugbot re-reviewed 9abb2d9 and found no new issues.
• 454b068 carries Fix vex alias tests broken by store-copy merge #851's test-only fix for two vex_consumed alias tests that main also fails (Fix npm store copies missed by agent apply and vex (#601, #603) #605 and Fix agent mode skipping npm-aliased copies (#356) #738 conflicted once both merged). It becomes a no-op once Fix vex alias tests broken by store-copy merge #851 merges. coverage, test-release and the composer Windows job, which failed on 2ab819a, now pass on 454b068.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DPHxnE5P1rkfCpHFFCwzFR

Generated by Claude Code