GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Fix vendored npm VEX beside a file: dir copy (#1511) by mikolalysenko · Pull Request #1513 · SocketDev/socket-patch

Conversation

@mikolalysenko

@mikolalysenko Mikola Lysenko (mikolalysenko) commented Oct 14, 2026 •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Collaborator

LLM Description written by Claude Code:claude-opus-5-5

Fixes #1511

Summary

In an npm workspace under install-strategy=nested, member a uses registry [email protected] and member b depends on a file: directory that holds the same release. A vendored scan --vex and a standalone vex both said not_affected, and vendor --check passed. But b's copy is a symlink to that directory, which no rewrite reaches, so it stays unpatched.

After this PR:

  • VEX: the vendored run's in-run --vex and a standalone vex attest nothing. They warn patched_ref_unattributable and name packages/b/node_modules/left-pad, as they already did for the file: tarball and URL shapes. Hosted mode has refused this shape since Fix npm file: copy attested by in-run VEX (#1481) #1482.
  • vendor --check: fails with copy unpatched: … naming that lock entry. Before this PR it passed. Without the second commit it would have failed with the false "wiring missing … re-run socket-patch vendor".

Root cause

vex::discover::npm::drop_non_registry_installs withholds a Socket-wired ref when a non-registry copy of the same name@version installs beside it. It read the copy's identity only from the entry's version. npm records a file: directory dependency as a versionless link entry ("resolved": "lpdir", "link": true), and only the directory's own entry carries the version. So the loop skipped it and the ref stayed attested. #1482 added that link → source lookup (npm_link_source_identity) to the hosted rewriter only. Discovery, which vendored VEX and vendor --check read, never got it.

Changes

  1. npm_link_source_identity moves from patch/redirect/mod.rs to vendor::npm_origin, next to npm_non_registry_entries. It now takes the link entry rather than a JSON pointer. The hosted rewriter and discovery both call it.
  2. Discovery resolves a versionless link entry that npm installs from a file: spec through that lookup. As in the hosted rewriter, only entries in npm_non_registry_entries qualify, so a plain workspace-member link is still first-party source.
  3. New Discovery::vendored_shadow: when a vendored claim died because its ref was moved to shadowed (an unpatched copy beside it), vendor --check quotes the diagnostic that names the copy. It no longer says nothing wires the artifact or tells the user to re-vendor. This also corrects the message for the existing bundled / git / url / file: tarball shapes. CLI_CONTRACT.md's vendor --check paragraph documents the new copy unpatched reason.

Tests (red → green)

Issue Test Without fix With fix
#1511 discovery (hosted and vendored wiring; named and folder-named source; controls for another version and a workspace-member namesake) socket-patch-core vex::discover::npm::tests::a_file_directory_link_copy_of_the_same_release_is_not_attested fails (1 ref attested) passes
#1511 vendored vendor --vex, standalone vex, vendor --check socket-patch-cli --test in_process_vendor vendor_npm_file_directory_copy_is_not_attested fails: exit 0, "vex":{"statements":1} (the issue's exact symptom) passes

Not changed (review notes)

  • The vendored rewriter still labels the file: directory's own source entry vendor_workspace_member_skipped. That label comes from npm vendored refuses a registry package with vendor_workspace_member whenever a local file: directory (or workspace member) has the same name@version, and the hosted→vendored takeover then un-hosts it, leaving it unpatched #688 and is documented in the contract's error-code table, and namesake_local_directory_does_not_block_registry_copies pins it. Renaming it to a loud vendor_non_registry_entry_skipped is a contract change, so I've left it as a possible follow-up. The run's own --vex warning and vendor --check now name the unpatched copy, so the outcome is no longer silent.
  • /code-review high flagged a scoped (@scope/name) folder-name case with no test. That branch of npm_link_source_identity is unchanged code from Fix npm file: copy attested by in-run VEX (#1481) #1482.

Local verification (head 7b7f58c)

  • cargo fmt --all -- --check: clean. cargo clippy --workspace --all-features -- -D warnings: clean.
  • cargo test --workspace --all-features (run in chunks because of the sandbox's disk allowance): every suite passes except 10 write-failure tests that rely on read-only permissions (relax_loop_must_not_traverse_symlinked_root, an_unremovable_hidden_lock_keeps_every_store_entry, wire_write_failure_*, wire_failure_rolls_back_*, *_state_write_failure_*, partial_lockfile_write_failure_*, redirect_json_mode_write_failures_*, scan_redirect_vlt_heal_invalidation_failure_warns). The sandbox runs as root, which bypasses those permissions. The tests are unrelated to this diff, and CI runs them as a non-root user.
  • e2e_vendor_npm_build and e2e_redirect_npm_build with --include-ignored on real npm 10.9.4: 36 and 43 passed.
  • /code-review high ran on the diff. Fixed from it: the vendor --check false "wiring missing" diagnosis, the link lookup gated to file: entries, the vacuous in-run VEX assertion, the missing workspace-member control, and the split name derivation. Not fixed, with reasons under "Not changed".
  • No wrapper changes needed: npm/, pypi/ and gem/ only dispatch to the binary.

🤖 Generated with Claude Code


Generated by Claude Code

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
@claude
Start fix for #1511
7202e08
Assisted-by: Claude Code:claude-opus-5-5
@mikolalysenko Mikola Lysenko (mikolalysenko) mentioned this pull request Oct 14, 2026
Vendored npm vex and scan --mode vendored --vex attest not_affected beside a file: directory copy of the patched name@version, which npm installs unpatched #1511
Closed
Claude (claude) added 2 commits October 14, 2026 00:32
@claude
Don't attest npm beside a file: dir copy
5bb379e
Vendored `scan --vex`, a standalone `vex` and `vendor --check` read the
npm lock through discovery, which skipped a `file:` directory
dependency: npm records it as a link entry with no version, so
discovery never saw that it holds the patched release. VEX then said
`not_affected` while that workspace member loaded the unpatched
directory.

Discovery now resolves such a link to its source directory's entry,
as the hosted rewriter does since #1482, and withholds the reference
with `patched_ref_unattributable`. The lookup moves to
vendor::npm_origin so both readers share it.

Fixes #1511

Assisted-by: Claude Code:claude-opus-5-5
@claude
Name the unpatched copy in vendor --check
7b7f58c
With the #1511 fix, `vendor --check` on a project whose vendored npm
package also installs from a `file:` directory failed with "wiring
missing: no lockfile or config references ... re-run socket-patch
vendor". The lock does reference the artifact, and re-vendoring cannot
reach that copy, so the advice looped. The same held for a bundled,
git, url or `file:` tarball copy.

The check now reports `copy unpatched:` with the lock entry that
installs the unpatched copy, and says to depend on the registry
release there instead.

Discovery's link lookup is also limited to entries npm installs from a
`file:` spec, as in the hosted rewriter, and the regression tests gain
a workspace-member control and assert the in-run VEX warning.

Refs #1511

Assisted-by: Claude Code:claude-opus-5-5
@mikolalysenko Mikola Lysenko (mikolalysenko) mentioned this pull request Oct 14, 2026
Swarm health manager log #1382
Open
@mikolalysenko
Mikola Lysenko (mikolalysenko) marked this pull request as ready for review October 14, 2026 01:06
@mikolalysenko

Mikola Lysenko (mikolalysenko) commented Oct 14, 2026

Copy link
Copy Markdown
Collaborator Author

BugBot review


Generated by Claude Code

cursor[bot] reacted with thumbs up emoji
All reactions
  • 👍 1 reaction

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

cursor[bot]
cursor Bot reviewed Oct 14, 2026
View reviewed changes

@cursor cursor Bot left a comment

Copy link
Copy Markdown

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

Reviewed by Cursor Bugbot for commit 7b7f58c. Configure here.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
Tanmay182003
Tanmay Singla (Tanmay182003) approved these changes Oct 14, 2026
View reviewed changes
@mikolalysenko
Mikola Lysenko (mikolalysenko) added this pull request to the merge queue Oct 14, 2026
Merged via the queue into main with commit 81dd140 Oct 14, 2026
86 checks passed

Uh oh!

There was an error while loading. Please reload this page.

@mikolalysenko
Mikola Lysenko (mikolalysenko) deleted the agent/fix-npm-vendored-file-dir-copy branch October 14, 2026 01:57
This was referenced Oct 14, 2026
CI perf (settings): slow Depot 16-core hosts since 10-13 15:20 add ~1.5–2.5 min to the merge-queue critical path (~0.6k Linux job-min/day) #1512
Open
vendor --check fails a vendored npm package that has a bundled duplicate with "wiring missing: no lockfile or config references …", although the lock does reference it, and its socket-patch vendor remedy is a no-op #1232
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@cursor cursor[bot] cursor[bot] left review comments
@Tanmay182003 Tanmay Singla (Tanmay182003) Tanmay182003 approved these changes

Uh oh!

There was an error while loading. Please reload this page.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Vendored npm vex and scan --mode vendored --vex attest not_affected beside a file: directory copy of the patched name@version, which npm installs unpatched

Uh oh!

There was an error while loading. Please reload this page.

3 participants

@mikolalysenko @Tanmay182003 @claude
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.