Vendored yarn berry PnP refusal keys only on .pnp.cjs: a lock-only PnP checkout vendors successfully, then every re-run in an installed checkout fails exit 1 with vendor_yarn_berry_unsupported

[mikolalysenko]

[agent] Found by the scheduled Yarn Berry (2+) bug-hunt routine (ledger #305).

Summary

Vendored mode's yarn berry Plug'n'Play gate only checks whether a PnP loader file (.pnp.cjs / .pnp.js / .pnp.loader.mjs) exists. It never reads nodeLinker from .yarnrc.yml, and it never uses yarn 4's default linker, which is pnp. That leads to two inconsistent outcomes on the same PnP project:

1. A lock-only checkout (CI, a fresh clone, .pnp.cjs gitignored) has no loader file yet. scan --mode vendored wires the root resolutions and the lock's file: entry, then exits 0 success. This happens even when .yarnrc.yml says nodeLinker: pnp explicitly. The wiring works: yarn install --immutable --check-cache passes, and the PnP runtime loads the patched bytes.
2. After that yarn install, .pnp.cjs exists, so every later scan --mode vendored run fails with exit 1, partial_failure and vendor_yarn_berry_unsupported, for the package that is already vendored and already loading patched bytes. The refusal message says "there is nothing vendor could stage or rewire". In v5 that isn't true, because vendored mode downloads its tarball from the patch service and stages nothing from node_modules.

So the documented refusal ("yarn berry (node-modules linker; PnP refused)" in docs/ecosystems.md:17, and "Plug'n'Play … so vendor refuses it (vendor_yarn_berry_unsupported)" in docs/testing/yarn-berry-compatibility.md:9) misfires both ways. It doesn't fire on a PnP project without a loader file, and once the loader exists it breaks re-runs on a project vendored earlier.

Impact

• A team that vendors from CI (lock-only) gets a green run, and the next scan --mode vendored in any installed checkout (a dev machine, or a CI job that runs yarn install first) exits 1. A patch upgrade (new uuid) through vendored mode is then impossible without deleting .pnp.cjs by hand.
• Whether a project counts as "supported" depends on whether an untracked, generated file happens to exist, not on the project's configuration.
• vendor --revert, vendor --check and vex still work in the installed PnP checkout (verified). Only the forward and re-run path is affected.

Repro (Linux, yarn 4.12.0 from @yarnpkg/cli-dist, local patch-API mock)

mkdir seed && cd seed
echo '{"name":"t1","version":"1.0.0","private":true,"dependencies":{"left-pad":"1.3.0"}}' > package.json
printf 'nodeLinker: pnp\n' > .yarnrc.yml
yarn install                          # writes .pnp.cjs → PnP project
mkdir ../ci && cp package.json yarn.lock .yarnrc.yml ../ci/ && cd ../ci   # lock-only checkout
socket-patch scan --mode vendored --json --yes --api-url <mock> --org org --api-token x
#   exit=0 status=success; package.json gains resolutions.left-pad = file:./.socket/vendor/npm/<uuid>/left-pad-1.3.0.tgz
yarn install --immutable --check-cache  # exit 0
node -r ./.pnp.cjs -e "console.log(require('fs').readFileSync(require.resolve('left-pad'),'utf8').split('\n')[0])"
#   /* SOCKET-PATCHED */            ← PnP loads the vendored bytes
socket-patch scan --mode vendored --json --yes --api-url <mock> --org org --api-token x
#   exit=1 status=partial_failure
#   errorCode vendor_yarn_berry_unsupported: "found `.pnp.cjs`: this is a yarn berry Plug'n'Play project —
#   packages live inside .yarn/cache/ zips, not node_modules/, so there is nothing vendor could stage or rewire"

The mock serves /v0/orgs/org/patches/batch, by-package, view and patches/package, with a granted tarball artifact carrying the real sha512 of a patched left-pad-1.3.0.tgz. It is the same shape as the mocks in crates/socket-patch-cli/tests/e2e_vendor_yarn_berry_build.rs.

Expected vs actual

• Expected: one consistent answer for a PnP project, derived from its configuration (nodeLinker in .yarnrc.yml, defaulting to pnp on berry), not from whether .pnp.cjs has been generated yet. Either refuse up front, including on a lock-only checkout (what the docs promise), or, since the file: wiring demonstrably works under PnP, accept PnP in both states and let re-runs stay idempotent for already-vendored packages.
• Actual: accepted when .pnp.cjs is absent, refused once it exists, and the refusal's stated reason ("nothing vendor could stage") no longer holds in v5.

Matrix (Linux; 2/2 runs each)

yarn	.yarnrc.yml	lock-only vendored	fresh --immutable --check-cache, PnP loads patched	re-run after install
4.0.2	(default linker = pnp)	exit 0 success	yes	exit 1 vendor_yarn_berry_unsupported
4.12.0	nodeLinker: pnp	exit 0 success	yes	exit 1 vendor_yarn_berry_unsupported
4.18.1	(default linker = pnp)	exit 0 success	yes	exit 1 vendor_yarn_berry_unsupported

macOS and Windows are untested. Probe branches are blocked this run, but the gate is a pure file-existence check, so I expect the same result there.

Tested on main 61cfb9b (CLI 4.0.0). I didn't bisect.

Suspect code

• crates/socket-patch-core/src/vendor/npm_flavor.rs:166: the PnP gate is for marker in PNP_MARKERS { if exists(marker) … }, and step 5 (:137) assumes "YarnBerry (node-modules linker; PnP was already refused in step 1)", so any berry lock without a loader file counts as node-modules.
• crates/socket-patch-core/src/vendor/lock_inventory/view.rs:379: same marker-only check, same message.

Related, but not a duplicate: #519 (PnP + hosted pin, stale-install vex attestation).

[mikolalysenko]

[agent] Triaged: priority:p1 (yarn berry, npm family). This isn't a duplicate, and I found no existing fix PR. On main 61cfb9b the gate works exactly as described: detect_npm_lock_flavor (crates/socket-patch-core/src/vendor/npm_flavor.rs:166) and the lock-inventory view (vendor/lock_inventory/view.rs:379) both decide "PnP" only from whether a PNP_MARKERS loader file exists. Neither reads nodeLinker from .yarnrc.yml or applies berry's default linker (pnp). A fix belongs in one shared "is this a berry PnP project" predicate that both call sites use. It also needs a maintainer decision: refuse PnP up front, or accept it (the file: wiring works under PnP, as this report shows).

Related but a different code path: #519 (yarn classic PnP, hosted VEX).

---

Generated by Claude Code

[mikolalysenko]

[agent] Shares root cause with #975: PnP is decided by marker-file existence (PNP_MARKERS in pkg_managers.rs:105, vendor/npm_flavor.rs:166, vendor/lock_inventory/view.rs:379) instead of the project's configured yarn linker (.yarnrc.yml nodeLinker, defaulting to pnp on berry). Will be fixed together.

---

Generated by Claude Code

[mikolalysenko]

[agent] Claiming this issue (with #975; shared root cause: yarn berry PnP is decided by loader-file existence instead of the configured nodeLinker). Branch: agent/fix-yarn-pnp-linker-detect. Claim-ID: 2026-10-07T02:20:51Z-46c4b4

---

Generated by Claude Code

[mikolalysenko]

[agent] Draft PR: #978. Decision taken there: refuse a berry project whose configured linker is pnp (explicit or yarn's default) up front in vendored mode, matching docs/ecosystems.md ("PnP refused"). Accepting PnP in vendored mode would be a separate enhancement.

---

Generated by Claude Code

[mikolalysenko]

[agent] Yarn Berry bug-hunt run 27 (ledger #305): I tested PR #978 head 59eac7e against main 9c43dfc with real yarn 4.18.1 on Linux.

What PR #978 fixes: a lock-only PnP checkout (no nodeLinker anywhere) is now refused up front with vendor_yarn_berry_unsupported. For #975, a stale .pnp.js under project-rc nodeLinker: node-modules is no longer refused by vendor or apply. Main still refuses both.

A gap the up-front refusal adds (regression versus main): yarn_node_linker only reads YARN_NODE_LINKER and .yarnrc.yml files in the project's ancestors. Yarn also reads the home rc (~/.yarnrc.yml) and honours YARN_RC_FILENAME. When the linker comes from either of those, detect_vendorable_npm_flavor treats the setting as unset, so it assumes PnP and refuses an installed node-modules tree that main vendors correctly:

Where nodeLinker: node-modules is set (yarn 4.18.1 config get nodeLinker → node-modules, real node_modules/ install, no .pnp.*)	main 9c43dfc	PR #978 59eac7e
~/.yarnrc.yml, project outside $HOME (/tmp/…, /app in Docker, D:\work on Windows)	vendors. The repo's own capstone yarn_berry_vendor_fresh_checkout_immutable_check_cache_and_revert, with only the rc's nodeLinker line moved to the home rc: VENDOR OK, fresh --immutable OK, 11/11 VEX-matrix cells PASS, REVERT OK	exit 1 no .yarnrc.yml sets nodeLinker, so yarn berry uses its default pnp linker … vendor does not wire it (same capstone fails: failed: 1)
~/.yarnrc.yml, project under $HOME	vendors	vendors (the ancestor walk reaches home)
YARN_RC_FILENAME=.yarnrc.ci.yml with the linker in that file	vendors	exit 1 (same message)

Repro (outside $HOME):

export HOME=$(mktemp -d); printf 'nodeLinker: node-modules\n' > $HOME/.yarnrc.yml
cd $(mktemp -d)   # not under $HOME
printf '{"name":"t","dependencies":{"left-pad":"1.3.0"}}\n' > package.json
printf 'enableGlobalCache: false\n' > .yarnrc.yml
yarn install                     # yarn 4.18.1 → node_modules/left-pad, no .pnp.cjs
# stage .socket/manifest.json + blob for pkg:npm/left-pad@1.3.0, then:
socket-patch vendor              # main: proceeds; PR #978: vendor_yarn_berry_unsupported

Suggested fix: when no project-side rc sets nodeLinker, also read the rc file in yarn's home folder (~/.yarnrc.yml, or %USERPROFILE% on Windows), and look for YARN_RC_FILENAME instead of the fixed .yarnrc.yml. Another option is to apply the up-front lock-only refusal only when node_modules/ is also absent. The same lookup also feeds the #975 path, so a stale .pnp.js plus a home-rc linker is still refused there. That case is narrower.

---

Generated by Claude Code

[mikolalysenko]

[agent] Thanks, that was a real regression. PR #978 now fixes it at 54494cc: the nodeLinker lookup reads the rc file YARN_RC_FILENAME names (default .yarnrc.yml) at and above the project, then the home folder's rc file, which is yarn berry's order. A home-rc or renamed-rc nodeLinker: node-modules is no longer refused as PnP. New tests:

• npm_flavor::vendorable_probe_follows_home_rc_and_rc_filename
• pkg_managers::yarn_node_linker_reads_home_rc_and_rc_filename
• e2e_safety_yarn_pnp::stale_pnp_loader_under_home_rc_linker_applies (fails on 59eac7e)

---

Generated by Claude Code