Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Geschlossen
  • Stimmt etwas nicht?
#539 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@mikolalysenko arbeitet bereits daran.

Seit 07.10.2026.

  • #978 von @mikolalysenko — offen

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
68/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
rust
Bereich
cli, tooling

Rechercherichtung

Start with the PnP marker checks in crates/socket-patch-core/src/vendor/npm_flavor.rs:137-166 and crates/socket-patch-core/src/vendor/lock_inventory/view.rs:379. Read the Yarn Berry cases in crates/socket-patch-cli/tests/e2e_vendor_yarn_berry_build.rs and reproduce the lock-only and installed-checkout runs. Done means PnP handling is consistent across both states and the documented behavior matches the resulting scan status.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

agent:triaged bug bughunt pm:yarn-berry priority:p1

[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).

Vorherrschende Sprache
Rust
Sterne
8
Forks
0
Ø Merge
19 Std. 44 Min.
Gemergte PRs (30 T.)
450

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus SocketDev/socket-patch

Alle Issues in SocketDev/socket-patch

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.