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 摘要。