Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Cerrado
  • ¿Algo no está bien?
#539 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@mikolalysenko ya está trabajando en esto.

Desde el 7/10/2026.

  • #978 de @mikolalysenko — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
68/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
rust
Área
cli, tooling

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
Rust
Estrellas
8
Forks
1
Merge medio
19 h 1 min
PR fusionados (30 d)
473

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de SocketDev/socket-patch

Todos los issues de SocketDev/socket-patch

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.