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

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

Offen Anfängerfreundlich
  • Stimmt etwas nicht?
#900 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
75/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
rust
Bereich
cli

Rechercherichtung

Beginne in crates/socket-patch-cli/src/commands/vendor.rs im Bereich der Zeilen 1036-1046. Die Funktion discovery.vendor_entry_live(root, entry) gibt sowohl für fehlende Referenzen als auch für umstrittene Referenzen (patched_ref_unattributable) false zurück, aber die Fehlermeldung behandelt nur den ersten Fall. Aktualisiere die Logik, um den Konflikt zu erkennen und die zugehörige Schwester-Lockdatei namentlich zu melden, mit dem Vorschlag zur Neuverdrahtung oder Löschung. Überprüfe dies, indem du die Vendor-Check-Testsuite ausführst.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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

Vorherrschende Sprache
Rust
Sterne
8
Forks
0
Ø Merge
1 T. 7 Min.
Gemergte PRs (30 T.)
178

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.