Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem 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

Đang mở Phù hợp với người mới
  • Có gì không ổn?
#900 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
75/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
rust
Lĩnh vực
cli

Hướng nghiên cứu

Bắt đầu tại crates/socket-patch-cli/src/commands/vendor.rs xung quanh các dòng 1036-1046. Hàm discovery.vendor_entry_live(root, entry) trả về false cả cho các tham chiếu bị thiếu và các tham chiếu bị tranh chấp (patched_ref_unattributable), nhưng thông báo lỗi chỉ xử lý trường hợp đầu tiên. Cập nhật logic để phát hiện tranh chấp và báo cáo tệp lockfile anh em theo tên, đề xuất kết nối lại hoặc xóa. Xác minh bằng cách chạy bộ kiểm tra vendor.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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

Ngôn ngữ chính
Rust
Star
8
Fork
0
Merge trung bình
1 ngày 7 phút
Pull request đã merge (30 ngày)
178

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của SocketDev/socket-patch

Tất cả issue của SocketDev/socket-patch

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.