Hacktoberfest 2026：維護者為十月標記出來的 issue，仍然開放、適合新手。 瀏覽 Hacktoberfest issue

Human `scan --mode vendored --prune` silently skips the vendored GC when no remaining package has a patch, so an `npm uninstall`ed vendored entry is never reverted (exit 0), while `--json` reverts it and `vendor --check` keeps pointing at that same command

未關閉 適合新手
  • 哪裡不對？
#1,127 1 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
2/5
預估耗時
1-3 小時
新手友好度
85/100
Issue 類型
缺陷
描述清晰度
描述清楚
活躍度
活躍
技術堆疊
rust
領域
cli

研究方向

根本原因在 crates/socket-patch-cli/src/commands/scan/mod.rs 的第 2673 行和第 2688 行附近：當 all_packages_with_patches 為空時，提前返回會略過 vendored GC。修改控制流程，讓這種情況也執行 vendored GC，與 --json 路徑的行為一致。執行現有的 scan 測試套件，確認此修正能解決面向使用者的輸出與 JSON 輸出之間的差異。

由索引模型根據 Issue 內容生成。

描述

agent:triaged bug bughunt pm:npm priority:p1

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

Summary

You vendor a patched npm dependency, then remove it with npm uninstall. vendor --check then exits 1 with dependency removed … run socket-patch scan --mode vendored --prune to revert the vendored entry. When none of the project's remaining packages has a patch, running that command in human mode prints No patches available for installed packages., exits 0, and does nothing. The ledger entry and .socket/vendor/npm/<uuid>/ stay, and vendor --check still exits 1. The same command with --json does revert the entry (gc.revertedVendoredEntries: ["pkg:npm/[email protected]"]).

Impact

  • The documented cleanup command doesn't work in the most common case: you removed your only patched dependency, or the only one left is unpatched. vendor --check sends you to it, it exits 0, and vendor --check still fails. CI that gates on vendor --check stays red until someone uses --json (by accident) or vendor --revert.
  • Because --prune is set, the vendor_ledger_entry_unwired warning is suppressed (prune_reverts_unwired, scan/mod.rs:1843). The human run gives no hint that anything was left behind.
  • Human and --json output disagree about what the same command writes.

Repro (npm 10.9.4 / Node 22, also npm 12.2.0 / Node 24; local mock of the public patch proxy serving a free patch for [email protected])

mkdir p && cd p
echo '{"name":"p","version":"1.0.0","dependencies":{"left-pad":"1.3.0","ms":"2.1.3"}}' > package.json
npm install
socket-patch scan --mode vendored            # exit 0, left-pad vendored
npm uninstall left-pad                        # ms has no patch
socket-patch vendor --check; echo $?          # "dependency removed … run `socket-patch scan --mode vendored --prune`", 1
socket-patch scan --mode vendored --prune; echo $?
#   Found 1 package (1 npm)
#   No patches available for installed packages.
#   0
ls .socket/vendor/npm                         # 11111111-… still there; state.json still has left-pad
socket-patch vendor --check; echo $?          # still 1
socket-patch scan --mode vendored --prune --json | jq .gc.revertedVendoredEntries
#   ["pkg:npm/[email protected]"]   ← JSON reverts it

Control: when a remaining package does have a patch (the mock also serves [email protected]), the human run prints GC: reverted 1 vendored entry and vendor --check goes green. When no packages are left at all, the zero-package path runs gc::run_vendor_only_gc, so that case works too. Only "packages found, none patched" is broken.

Expected vs actual

  • Expected (CLI_CONTRACT.md, vendored mode paragraph): "an entry the lockfile in-use probe … proves unwired … A run without a non-hosted --prune reports it through the run-level vendor_ledger_entry_unwired warning; a --prune run reverts it in its GC and exits 0. That GC runs even when the crawl found no packages". Also the scan --prune paragraph: "(b) EVERY ledger entry whose dependency is no longer in the lockfile graph is reverted".
  • Actual: human mode, packages found but no patches: no GC, no warning, exit 0. --json: GC runs and reverts the entry.

Matrix (Linux)

npm human --prune reverts --json --prune reverts runs
10.9.4 (Node 22.22) no yes ×3 (incl. a workspace member npm uninstall -w a)
12.2.0 (Node 24) no n/a (not re-run) ×1
10.9.4, a patched package remains yes yes ×1 (control)

This is not OS-specific: it comes from scan control flow, not from the filesystem, so I didn't push a probe branch. It's not npm-specific either: any vendored ecosystem whose remaining packages have no patches should hit it. v4.0.0 can't vendor against this mock (a different vendoring flow), so there's no release bisect. main's history is grafted at 23fd62e, so the first bad commit can't be bisected.

Suspect code (main e2d9633)

  • crates/socket-patch-cli/src/commands/scan/mod.rs:2688: if all_packages_with_patches.is_empty() { … return finish_human(0).await; }
  • crates/socket-patch-cli/src/commands/scan/mod.rs:2673: finish_human runs the GC only if prune && !vendor && !hosted, because the vendored arm "runs its own". On this early return the vendored arm never runs, so nothing does.
  • The JSON path runs gc_json (scan/mod.rs:2633) regardless, which is why --json works.
  • scan/mod.rs:1843-1844: prune_reverts_unwired suppresses the vendor_ledger_entry_unwired warning on the assumption that the GC will run.
主要語言
Rust
星號
8
分支
0
平均合併
1 天 1 小時
30 天內合併 PR
257

環境準備

  • 沒有 Dockerfile 或 Docker Compose 檔案
  • 沒有 Pull Request 範本
  • 閱讀貢獻指南

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

SocketDev/socket-patch 的其他 Issue

查看 SocketDev/socket-patch 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。