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

Root `scan --mode vendored` exits 1 forever and drops its in-run VEX when a nested independent npm project installs a patched package the root lock doesn't have (hosted mode only warns)

未關閉
#1,534 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
4/5
預估耗時
1-2 天
新手友好度
45/100
Issue 類型
缺陷
描述清晰度
描述清楚
活躍度
活躍
技術堆疊
nodejs, rust
領域
build-system, cli

研究方向

Start in crates/socket-patch-cli/src/commands/scan/mod.rs around lines 1788-1796, where hosted and vendored scans skip judge_nested_roots, then compare with the redirect_npm_entry_not_found warning path. The vendor backend's hard vendor_lock_entry_not_found refusal is in crates/socket-patch-core/src/vendor/npm_lock.rs around lines 534-540. Done means a root vendored scan with an independent nested npm project exits 0, emits a warning naming the nested PATH, and still writes the in-run VEX.

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

描述

bug bughunt pm:npm

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

Summary

A repository root is an npm project. tools/x/ is a separate npm project, not a workspace member, with its own package-lock.json and node_modules. It depends on a package that has a patch and that the root doesn't depend on.

socket-patch scan --mode vendored from the root crawls tools/x/node_modules (documented in docs/ecosystems.md, "npm: which node_modules trees are crawled"), downloads the patch, and passes the package to the root package-lock.json vendor backend. The backend refuses with vendor_lock_entry_not_found, so the run ends partialFailure, exit 1. That happens on every run: nothing the user can do at the root clears it.

scan --mode hosted over the same tree skips the package with redirect_unconfirmed / redirect_npm_entry_not_found, and exits 0. The scan code says nested copies are out of scope for both modes: crates/socket-patch-cli/src/commands/scan/mod.rs:1789-1791 reads "Hosted and vendored scans only rewire this root's lockfiles".

The Bun routine found this first on Bun 1.3.x and npm 10 and handed it over (ledger #302 entry 20261014T042736Z-from-bun). This issue is the npm reproduction.

Impact

  • CI is permanently red. A root scan --mode vendored in any repo with an independent nested npm project (examples/, docs/, tools/) exits 1 every time. The root's own packages are vendored correctly and then reported as already vendored.
  • No in-run VEX. scan --mode vendored --vex out.vex.json exits 1 and writes no document, even after npm ci has installed the root's patched bytes. The same shape in hosted mode writes the VEX and exits 0. A standalone socket-patch vex from the root works (exit 0, attests the root's package), so the failure comes only from the scan treating the nested copy as a failure.
  • The remedy is wrong. It says "make sure the package is installed and locked (npm install)". The package is installed and locked, in tools/x. Running npm install at the root or in tools/x changes nothing.
  • The per-path form fails the same way. scan --mode vendored . tools/x vendors tools/x correctly, but its . leg still crawls tools/x/node_modules and fails, so the command exits 1. It stays red even after tools/x is vendored and reinstalled with patched bytes.

Repro

A local mock of the org patch API serves free patches for [email protected] and [email protected]. It answers batch, by-package, view and patches/package with a real patched tarball. Every socket-patch command gets --api-url <mock> --api-token fake --org test-org.

mkdir -p r/tools/x && cd r && git init -q && echo node_modules/ > .gitignore
echo '{"name":"root","private":true,"dependencies":{"minimist":"1.2.5"}}' > package.json
echo '{"name":"x","private":true,"dependencies":{"left-pad":"1.3.0"}}' > tools/x/package.json
npm install && (cd tools/x && npm install)

socket-patch scan --mode vendored --json --yes   # run 1: partialFailure, exit 1
socket-patch scan --mode vendored --json --yes   # run 2: partialFailure, exit 1 (minimist already_vendored)
npm ci
socket-patch scan --mode vendored --yes --vex out.vex.json --vex-product pkg:npm/[email protected]   # exit 1, no out.vex.json
socket-patch vex -O out.vex.json --product pkg:npm/[email protected] --offline                      # exit 0, attests minimist

# hosted control (fresh copy of the same tree)
socket-patch scan --mode hosted --json --yes --patch-server-url <mock>   # success, exit 0

Vendored output (npm 10.9.4, main 37c8918):

status: partialFailure            (exit 1)
  downloaded pkg:npm/[email protected]
  downloaded pkg:npm/[email protected]
  failed  pkg:npm/[email protected] vendor_lock_entry_not_found package-lock.json has no rewritable entry for [email protected] — make sure the package is installed and locked (`npm install`) before vendoring
  applied pkg:npm/[email protected]

Hosted output for the same tree:

status: success                   (exit 0)
  skipped pkg:npm/[email protected] redirect_unconfirmed no lockfile entry pinning it could be rewritten
  applied pkg:npm/[email protected]
  W redirect_npm_entry_not_found: no package-lock.json entry for [email protected]

Expected vs actual

  • Expected. A hosted or vendored scan rewires only the scan root's lockfiles (scan/mod.rs:1789). A nested project is reached by passing its PATH (docs/configuration.md: "Each PATH in hosted or vendored mode is a project directory"). So a crawled copy that belongs to a nested project should get the same treatment as in hosted mode: a warning that names the nested project and the PATH to run, with no failed event and no effect on the exit code or the in-run VEX. CLI_CONTRACT.md's exit-code rules reserve partialFailure for packages the run should have patched and couldn't.
  • Actual. The run fails with exit 1 on every run, omits the in-run VEX, and gives a remedy (npm install) that can't clear it. scan . tools/x is also red.

Matrix

OS npm / Node socket-patch Reproduces
Linux 10.9.4 / Node 22.22 main 37c8918 yes (×3, incl. --vex and . tools/x)
Linux 12.2.0 / Node 22.22 main 37c8918 yes (×2 runs)
Linux 8.19.4 / Node 22.22 main 37c8918 yes (×2 runs)
Linux 10.9.4 / Node 22.22 v5.0.1 (npm latest) yes
Linux Bun 1.3.0 / 1.3.9 / 1.4.3 bb73e2f yes (Bun routine)
macOS / Windows — — untested (probe branches unavailable). The logic is OS-independent.

First bad: pre-existing. It is in v5.0.1 already.

Suspect code

  • crates/socket-patch-cli/src/commands/scan/mod.rs:1788-1796: agent and report-only scans call judge_nested_roots to assign each crawled copy to its own project root (#554). Hosted and vendored scans skip it, so vendored hands every crawled purl to the root backend.
  • crates/socket-patch-core/src/vendor/npm_lock.rs:534-540: an absent entry becomes the hard vendor_lock_entry_not_found refusal, where hosted's equivalent (redirect_npm_entry_not_found) is a warning plus a skip.

🤖 Generated with Claude Code

主要語言
Rust
星號
8
分支
1
平均合併
17 小時 5 分鐘
30 天內合併 PR
557

環境準備

  • 沒有 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 摘要。