GeezerVison

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

Fixes #1100

Summary

socket-patch now reads .yarnrc.yml settings the way yarn does. Before this change, a live Plug'n'Play project whose .yarnrc.yml said nodeLinker: "${L:-pnp}" got exit 0 and package_not_installed from agent apply instead of a yarn_pnp_unsupported refusal, and lock-only vendor passed its PnP gate. compressionLevel: "${CL:-0}" was refused as a non-default level, even though yarn reads it as 0.

Root cause

Every .yarnrc.yml setting socket-patch decides on (nodeLinker, compressionLevel, pnpmStoreFolder) went through yarnrc_scalar, a column-0 line scan that returned the literal text after key:. Yarn parses the file as YAML, expands ${NAME} / ${NAME-fallback} / ${NAME:-fallback} in every value (replaceEnvVariables), and matches yarn_* environment keys in any case. So socket-patch and yarn disagreed on:

• interpolated values (the fail-open regression from Fix yarn PnP detection ignoring nodeLinker (#975, #539) #978 and the false compressionLevel refusal),
• a quoted key, a value on the next line, or a flow-map document (refused as PnP),
• yarn_node_linker in lower case (ignored).

Fix

• New formats::yarn::rc module, a single reader for top-level .yarnrc.yml settings:
  • parses the file as YAML (granit parser, already a dependency) and lets the last occurrence of a key win, as yarn does;
  • a root that isn't a mapping sets nothing;
  • a file that isn't one YAML document falls back to the old line scan;
  • one implementation of yarn's replaceEnvVariables (expand_env), now also used by the npm registry restore (which keeps its rule that it never expands a set variable into a URL).
• nodeLinker (disk probe, in-memory hosted view, home rc, YARN_NODE_LINKER), the compressionLevel gate and the yarn pnpm-store check all read through it.
• Fails closed. A linker reference yarn can't expand (unset with no fallback, or expanding to nothing) counts as PnP while a loader exists. The vendor refusal names that value rather than claiming nodeLinker: pnp.
• Host-independent where the repository isn't on the host. The hosted in-memory view and the compressionLevel gate expand from an empty environment, so a reference passes only through its fallback. A level set in some install environment is already recorded in the lock's cacheKey, which the cache-key gate checks. Agent mode on disk expands from the process environment yarn would run in.
• Refusals name the value as written, so they never print an expanded environment variable.
• yarn_node_linker / yarn_rc_filename are matched in any case, in the order yarn uses (last spelling of a setting wins, first spelling of the rc file name).

The TS/Python/gem wrappers only dispatch to the binary, so they need no change.

Test evidence

Each issue row has a regression test. Every one was run red against main's core and green with the fix:

Commands run locally:

• cargo fmt --all -- --check: clean
• cargo clippy --workspace --all-features -- -D warnings: clean
• cargo test -p socket-patch-cli --all-features --test e2e_safety_yarn_pnp: 43 passed
• cargo test --workspace --all-features: every suite passes except 14 tests across 5 targets (covgap_commands_vendor, e2e_bun_lockb, in_process_redirect, repair, core lib), which fail identically on origin/main in this sandbox: write-failure and permission tests that do not hold when running as root (verified by running each on main)

/code-review high ran on the diff. These findings were fixed: host-env leakage in the memory view and the compression gate, env-key order, yarn_rc_filename case, a root list read as settings, an empty expansion inheriting a parent's linker, the misleading refusal text, and a dead wrapper. Not fixed:

• The npm registry restore still locates npmRegistryServer / npmScopes with its own line-based YAML path reader; only the expansion is shared now. Moving the nested npmScopes lookup onto a YAML tree is a separate change to the restore path, so it's left as a follow-up.
• An unexpandable linker is carried as its raw ${…} text rather than a typed state. That keeps the Option<String> linker API every caller uses, and a literal ${ in a linker isn't a value yarn accepts either way, so both read as PnP (fail closed).

🤖 Generated with Claude Code

Generated by Claude Code