Problem
Four warning-hygiene defects in the hosted redirect rewriters (audit 2026-08-13, crates/socket-patch-core/src/patch/redirect/mod.rs) made the warnings channel noisy or misleading — the same channel that carries the module's real signals (berry cache refusals, entry-not-found):
- Spurious
redirect_npm_no_lockfile on every pnpm/Rush project (mod.rs:174): rewrite_npm_lock warned "no package-lock.json / npm-shrinkwrap.json present" whenever its own lock was absent, with no regard for the sibling pnpm-lock.yaml (root or Rush common/config/rush/) that was successfully rewritten. A fully green Rush hosted run always carried the bogus warning in both --json warnings[] and human stderr.
- Same spurious warning on every yarn/bun-only scan (mod.rs:177): all yarn/bun deps are ecosystem "npm", so every hosted scan of a pure yarn or bun project emitted the noise even on complete success — training CI users to ignore warnings.
- Berry CRLF misdiagnosis (mod.rs:852): a CRLF yarn berry lock (which yarn itself parses fine) collapses the
\n\n block grammar, so berry_cache_key returned None and the refusal claimed cacheKey is `(missing)` — even though the lock's cacheKey IS 10c0. Windows-checkout users were sent chasing yarn cache/compression config instead of line endings.
- pnpm CRLF misdiagnosis (mod.rs:698): the pnpm rewrite pattern anchors on
):\n, which never matches CRLF lines, so a Windows-normalized pnpm-lock.yaml surfaced per-dep as a misleading redirect_pnpm_entry_not_found ("no inline resolution for X") though the entry exists.
Concrete failing scenario: scan --mode hosted --json on a pnpm-only project with one granted patch returned redirected: 1 with warnings: ["redirect_npm_no_lockfile", "redirect_pnpm_trust_lockfile"] — a fully successful run flagged with a lockfile complaint about a file the project should not have.
Fix
Warning hygiene only — zero behavior change to rewrites (CRLF locks were already never rewritten; they were only misdiagnosed).
rewrite_npm_lock now emits redirect_npm_no_lockfile only when NO npm-family lockfile is present at all: a sibling yarn.lock, bun.lock/bun.lockb, or pnpm-lock.yaml (root or nested Rush) suppresses it, since that lock's own rewriter carries the per-dep diagnostics (findings 1+2 are the same defect at one boundary and share this fix). A genuinely lockfile-less project still warns, unchanged.rewrite_yarn_berry detects CRLF content before the cacheKey gate and refuses with a new redirect_yarn_berry_crlf_unsupported warning naming the line endings and the LF remedy — same fail-closed outcome, honest diagnosis. Placed after the __metadata: berry-detection gate, so CRLF classic locks are untouched by this code (classic CRLF handling is a separate audit lane: classic-hosted-crlf, deliberately not addressed here).rewrite_pnpm_lock skips each CRLF lock up front with a new per-file redirect_pnpm_crlf_unsupported warning naming the lock path, instead of the per-dep entry-not-found; if no LF lock remains it returns before the dep loop. Mixed CRLF+LF lock sets proceed on the LF locks unchanged.
New warning codes: redirect_yarn_berry_crlf_unsupported, redirect_pnpm_crlf_unsupported — both fail-closed refusals.
Testing
- New rewriter unit tests (in
redirect/mod.rs): exact-empty warning set on clean npm and pnpm success; redirect_npm_no_lockfile gating across yarn-only, Rush-nested-pnpm-only, and lockfile-less projects; CRLF berry lock with cacheKey: 10c0 diagnosed as exactly redirect_yarn_berry_crlf_unsupported with no rewrite; CRLF pnpm v9 lock diagnosed as exactly redirect_pnpm_crlf_unsupported (naming the file) with no rewrite.
- New subprocess
--json envelope test (in_process_redirect.rs): clean_success_warning_set_is_exact_for_npm_and_pnpm pins the EXACT warning set (npm success = empty; pnpm success = exactly redirect_pnpm_trust_lockfile). Independently verified RED against pre-fix code by the reviewer: the pre-fix envelope carried ["redirect_npm_no_lockfile", "redirect_pnpm_trust_lockfile"].
- Suites green:
cargo test -p socket-patch-core --lib patch::redirect (59 passed), cargo test -p socket-patch-core --test redirect_golden (1 passed), cargo test -p socket-patch-cli --test in_process_redirect (24 passed), cargo test -p socket-patch-cli --test in_process_redirect_pnpm (3 passed).
- The pre-existing lockfile-less human-mode test (
redirect_human_mode_prints_rewriter_warnings) still passes — the warning still fires when no npm-family lock exists.
No skipped findings in this lane.
🤖 Generated with Claude Code
Note
Low Risk
Warning-only changes to hosted lock redirect diagnostics; rewrite behavior for LF locks is unchanged and covered by new exact-warning and CRLF tests.
Overview
Hosted redirect rewriters now emit fewer spurious warnings and clearer CRLF refusals without changing successful LF lock rewrites.
redirect_npm_no_lockfile is suppressed when another npm-family lock owns the redirect (yarn.lock, bun.lock/bun.lockb, root or nested pnpm-lock.yaml). Projects with no npm-family lock still get the same warning.
CRLF locks are rejected up front with new codes redirect_pnpm_crlf_unsupported and redirect_yarn_berry_crlf_unsupported (normalize to LF and re-run), instead of misleading redirect_pnpm_entry_not_found or berry cacheKey is (missing) diagnoses.
Tests pin exact warning sets on clean npm/pnpm success (npm empty; pnpm only redirect_pnpm_trust_lockfile from the CLI layer), sibling-lock gating, and CRLF messaging.
Reviewed by Cursor Bugbot for commit 706e078. Configure here.