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

Root `scan --mode vendored` exits 1 forever and drops its in-run VEX when a nested independent npm project installs a patched package the root lock doesn't have (hosted mode only warns)

Cerrado
  • ¿Algo no está bien?
#1,534 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Ya se ha fusionado un pull request relacionado.

  • #1543 de @mikolalysenko — fusionado

Evaluación

Dificultad
4/5
Tiempo estimado
1-2 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
nodejs, rust
Área
build-system, cli

Línea de trabajo

Start in crates/socket-patch-cli/src/commands/scan/mod.rs around lines 1788-1796, where hosted and vendored scans skip judge_nested_roots, then compare with the redirect_npm_entry_not_found warning path. The vendor backend's hard vendor_lock_entry_not_found refusal is in crates/socket-patch-core/src/vendor/npm_lock.rs around lines 534-540. Done means a root vendored scan with an independent nested npm project exits 0, emits a warning naming the nested PATH, and still writes the in-run VEX.

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

Descripción

bug bughunt pm:npm

[agent] Found by the scheduled npm bug-hunt routine (ledger #302).

Summary

A repository root is an npm project. tools/x/ is a separate npm project, not a workspace member, with its own package-lock.json and node_modules. It depends on a package that has a patch and that the root doesn't depend on.

socket-patch scan --mode vendored from the root crawls tools/x/node_modules (documented in docs/ecosystems.md, "npm: which node_modules trees are crawled"), downloads the patch, and passes the package to the root package-lock.json vendor backend. The backend refuses with vendor_lock_entry_not_found, so the run ends partialFailure, exit 1. That happens on every run: nothing the user can do at the root clears it.

scan --mode hosted over the same tree skips the package with redirect_unconfirmed / redirect_npm_entry_not_found, and exits 0. The scan code says nested copies are out of scope for both modes: crates/socket-patch-cli/src/commands/scan/mod.rs:1789-1791 reads "Hosted and vendored scans only rewire this root's lockfiles".

The Bun routine found this first on Bun 1.3.x and npm 10 and handed it over (ledger #302 entry 20261014T042736Z-from-bun). This issue is the npm reproduction.

Impact

  • CI is permanently red. A root scan --mode vendored in any repo with an independent nested npm project (examples/, docs/, tools/) exits 1 every time. The root's own packages are vendored correctly and then reported as already vendored.
  • No in-run VEX. scan --mode vendored --vex out.vex.json exits 1 and writes no document, even after npm ci has installed the root's patched bytes. The same shape in hosted mode writes the VEX and exits 0. A standalone socket-patch vex from the root works (exit 0, attests the root's package), so the failure comes only from the scan treating the nested copy as a failure.
  • The remedy is wrong. It says "make sure the package is installed and locked (npm install)". The package is installed and locked, in tools/x. Running npm install at the root or in tools/x changes nothing.
  • The per-path form fails the same way. scan --mode vendored . tools/x vendors tools/x correctly, but its . leg still crawls tools/x/node_modules and fails, so the command exits 1. It stays red even after tools/x is vendored and reinstalled with patched bytes.

Repro

A local mock of the org patch API serves free patches for [email protected] and [email protected]. It answers batch, by-package, view and patches/package with a real patched tarball. Every socket-patch command gets --api-url <mock> --api-token fake --org test-org.

mkdir -p r/tools/x && cd r && git init -q && echo node_modules/ > .gitignore
echo '{"name":"root","private":true,"dependencies":{"minimist":"1.2.5"}}' > package.json
echo '{"name":"x","private":true,"dependencies":{"left-pad":"1.3.0"}}' > tools/x/package.json
npm install && (cd tools/x && npm install)

socket-patch scan --mode vendored --json --yes   # run 1: partialFailure, exit 1
socket-patch scan --mode vendored --json --yes   # run 2: partialFailure, exit 1 (minimist already_vendored)
npm ci
socket-patch scan --mode vendored --yes --vex out.vex.json --vex-product pkg:npm/[email protected]   # exit 1, no out.vex.json
socket-patch vex -O out.vex.json --product pkg:npm/[email protected] --offline                      # exit 0, attests minimist

# hosted control (fresh copy of the same tree)
socket-patch scan --mode hosted --json --yes --patch-server-url <mock>   # success, exit 0

Vendored output (npm 10.9.4, main 37c8918):

status: partialFailure            (exit 1)
  downloaded pkg:npm/[email protected]
  downloaded pkg:npm/[email protected]
  failed  pkg:npm/[email protected] vendor_lock_entry_not_found package-lock.json has no rewritable entry for [email protected] — make sure the package is installed and locked (`npm install`) before vendoring
  applied pkg:npm/[email protected]

Hosted output for the same tree:

status: success                   (exit 0)
  skipped pkg:npm/[email protected] redirect_unconfirmed no lockfile entry pinning it could be rewritten
  applied pkg:npm/[email protected]
  W redirect_npm_entry_not_found: no package-lock.json entry for [email protected]

Expected vs actual

  • Expected. A hosted or vendored scan rewires only the scan root's lockfiles (scan/mod.rs:1789). A nested project is reached by passing its PATH (docs/configuration.md: "Each PATH in hosted or vendored mode is a project directory"). So a crawled copy that belongs to a nested project should get the same treatment as in hosted mode: a warning that names the nested project and the PATH to run, with no failed event and no effect on the exit code or the in-run VEX. CLI_CONTRACT.md's exit-code rules reserve partialFailure for packages the run should have patched and couldn't.
  • Actual. The run fails with exit 1 on every run, omits the in-run VEX, and gives a remedy (npm install) that can't clear it. scan . tools/x is also red.

Matrix

OS npm / Node socket-patch Reproduces
Linux 10.9.4 / Node 22.22 main 37c8918 yes (×3, incl. --vex and . tools/x)
Linux 12.2.0 / Node 22.22 main 37c8918 yes (×2 runs)
Linux 8.19.4 / Node 22.22 main 37c8918 yes (×2 runs)
Linux 10.9.4 / Node 22.22 v5.0.1 (npm latest) yes
Linux Bun 1.3.0 / 1.3.9 / 1.4.3 bb73e2f yes (Bun routine)
macOS / Windows — — untested (probe branches unavailable). The logic is OS-independent.

First bad: pre-existing. It is in v5.0.1 already.

Suspect code

  • crates/socket-patch-cli/src/commands/scan/mod.rs:1788-1796: agent and report-only scans call judge_nested_roots to assign each crawled copy to its own project root (#554). Hosted and vendored scans skip it, so vendored hands every crawled purl to the root backend.
  • crates/socket-patch-core/src/vendor/npm_lock.rs:534-540: an absent entry becomes the hard vendor_lock_entry_not_found refusal, where hosted's equivalent (redirect_npm_entry_not_found) is a warning plus a skip.

🤖 Generated with Claude Code

Lenguaje dominante
Rust
Estrellas
8
Forks
1
Merge medio
16 h 35 min
PR fusionados (30 d)
574

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.