Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue 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

Aperta Adatta ai principianti
  • Qualcosa non va?
#900 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
75/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
cli

Direzione di ricerca

Inizia in crates/socket-patch-cli/src/commands/vendor.rs intorno alle righe 1036-1046. La funzione discovery.vendor_entry_live(root, entry) restituisce false sia per i riferimenti mancanti che per i riferimenti contestati (patched_ref_unattributable), ma il messaggio di errore gestisce solo il primo caso. Aggiorna la logica per rilevare la contestazione e riportare il file lockfile fratello per nome, suggerendo il ricablaggio o l'eliminazione. Verifica eseguendo la suite di test di verifica del vendor.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
Rust
Stelle
8
Fork
0
Merge medio
1g 7m
PR unite (30g)
178

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di SocketDev/socket-patch

Tutte le issue di SocketDev/socket-patch

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.