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

vendor --check fails a vendored package whose lock is contested by a sibling package-lock.json with "no lockfile or config references .socket/vendor/… any more", which is false, and its remedy ("re-run socket-patch vendor") is a no-op, so the check stays red forever

Cerrado Apto para principiantes
  • ¿Algo no está bien?
#900 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
75/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
rust
Área
cli

Línea de trabajo

Comienza en crates/socket-patch-cli/src/commands/vendor.rs alrededor de las líneas 1036-1046. La función discovery.vendor_entry_live(root, entry) devuelve false tanto para referencias faltantes como para referencias en disputa (patched_ref_unattributable), pero el mensaje de error solo maneja el primer caso. Actualiza la lógica para detectar la disputa e informar el archivo lockfile hermano por su nombre, sugiriendo reconexión o eliminación. Verifica ejecutando la suite de pruebas de verificación de vendor.

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

Descripción

agent:triaged bug bughunt pm:npm priority:p1

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

Summary

Take a project with package-lock.json and another npm-family lock (yarn.lock, bun.lock) that both resolve [email protected] from the registry. scan --mode vendored wires the lock its backend selects (yarn.lock here) and warns vendor_multiple_lockfiles ("package-lock.json is not wired … installs driven by package-lock.json will still install the UNPATCHED registry bytes"), as documented. Since #730 (#725), vendor --check runs the lock-wiring probe, and it then exits 1 with:

pkg:npm/[email protected]: wiring missing: no lockfile or config references .socket/vendor/npm/<uuid> any more, so a fresh install gets the unpatched package; re-run `socket-patch vendor` to rewire it

yarn.lock does reference .socket/vendor/npm/<uuid>. The real reason is that package-lock.json contests it. Following the remedy changes nothing:

  • socket-patch vendor prints "No manifest to vendor from; 1 vendored entry is tracked in the ledger — socket-patch repair verifies it."
  • socket-patch scan --mode vendored prints "1 package is already vendored; nothing to do."
  • socket-patch repair is a no-op.

vendor --check stays exit 1 for good. vex diagnoses the same tree correctly ("yarn.lock: … wired …, but package-lock.json resolves the same version from elsewhere … rewire both locks … or delete the stale one", patched_ref_unattributable). But it then also prints the same false vendor_unwired line ("no lockfile or config wires it to this package any more").

Failing closed is right, because npm ci from package-lock.json installs unpatched bytes. The defect is the diagnostic: it names the wrong cause, and its only remedy is a command that can't fix it. The fix is to delete or rewire package-lock.json.

Impact

CI gating on vendor --check goes red after a successful vendored scan. The message and remedy send the user around a loop (vendor → repair → scan → still red), and nothing names package-lock.json.

Repro (Linux, main 9c43dfc, npm 10.9.4 + yarn 1.22.22)

A local mock patch API serves a free patch for pkg:npm/[email protected].

mkdir app && cd app
echo '{"name":"app","version":"1.0.0","dependencies":{"left-pad":"1.3.0"}}' > package.json
npm install && yarn install          # package-lock.json + yarn.lock
git init -q && echo node_modules > .gitignore && git add -A && git commit -qm init
socket-patch scan --mode vendored --json --yes --api-url $MOCK --org o --api-token x
#   exit 0, success; events: applied, vendor_multiple_lockfiles; yarn.lock rewired
socket-patch vendor --check           # exit 1, "wiring missing: no lockfile or config references … any more"
socket-patch vendor --yes             # "No manifest to vendor from; …"
socket-patch scan --mode vendored --yes   # "1 package is already vendored; nothing to do."
socket-patch repair --yes             # no change
socket-patch vendor --check           # still exit 1, same message

2/2 runs. The Bun routine saw the same thing with bun.lock + package-lock.json (Bun 1.4.2) and yarn 1.22.22 + npm 10 (handover on ledger #302).

Expected vs actual

  • Expected: vendor --check (CLI_CONTRACT's verification gate, and the same liveness rule as vex) should report the contest the way vex does: name package-lock.json as resolving the package from the registry, and suggest rewiring or deleting it. It shouldn't claim no lockfile references the artifact, or suggest a command that reports "nothing to do".
  • Actual: a false "no lockfile or config references" message, with a no-op remedy.

OS × version

OS locks vendor --check remedy loop
Linux package-lock v3 (npm 10.9.4) + yarn.lock (yarn 1.22.22) exit 1, false message (×2) vendor / scan / repair no-op
Linux package-lock (npm 10) + bun.lock (Bun 1.4.2), from the Bun routine same same
macOS / Windows not probed; no OS-specific code path

Not a regression in the usual sense: vendor --check didn't probe wiring before #730.

Suspect code

  • crates/socket-patch-cli/src/commands/vendor.rs:1036-1046: discovery.vendor_entry_live(root, entry) returns false both when no lock references the entry and when the reference is rejected as contested (patched_ref_unattributable). The message always assumes the first case.
  • The same conflation produces vex's trailing vendor_unwired line after its correct patched_ref_unattributable warning.

Related: #725 / #730 (added the probe), #798 / #799 (cross-lock contest), #656 (another remedy loop).

Lenguaje dominante
Rust
Estrellas
8
Forks
0
Merge medio
22 h 30 min
PR fusionados (30 d)
329

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.