Fix lockless nested npm projects in root scans (#1554)

[Mikola Lysenko (mikolalysenko)]

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

Fixes #1554

Summary

A root scan --mode vendored over a repo that holds an npm project installed without a lockfile (package-lock=false in its .npmrc, or npm install --no-package-lock) failed every run with vendor_lock_entry_not_found, exited 1 and dropped the in-run VEX. The suggested npm install couldn't clear it. Such a project is now treated like a nested project that has its own lock (#1534/#1543): its packages get a nested_project_skipped warning, and the root run succeeds and writes its VEX.

Root cause

nested_npm_project (crates/socket-patch-core/src/hosted/governing_root.rs) only counted a directory below the scan root as an independent project if it held its own npm-family lock. A lockless project was never recognised, so its copies stayed with the root's vendor backend, and the root lock never lists them.

Fix

• nested_npm_project checks lock roots first, as before. If none matches, it falls back to lockless_npm_project. That function takes the directory that owns the copy's first node_modules and, as long as a workspace lists it, climbs to that workspace's root. The result counts as independent when it sits strictly below the scan root and has a package.json.
• listing_workspace decides membership whether or not the workspace was ever locked. It reads package.json / vlt.json workspaces in every package manager's dialect, plus pnpm-workspace.yaml packages: via lists_as_member, which leans toward "member" when it can't tell. It also treats a Rush root as an owner. The walk stops at the scan root.
• The nested_project_skipped warning for a lockless project now says the project has no lockfile. It offers remedies that work: run npm install --package-lock there and then scan it, or socket-patch scan --mode agent <dir>. The old text claimed the project had its own lockfile and pointed to a hosted/vendored rerun, which would be refused. docs/ecosystems.md is updated to match.

Tests (red → green)

Issue	Test	Without fix	With fix
#1554 (core, incl. brace/unreadable pnpm globs after Bugbot)	governing_root::tests::nested_npm_project_finds_a_lockless_project	left: None, right: Some(".../tools/x")	pass
#1554 (core: pnpm root, Rush, member scan)	governing_root::tests::lockless_project_under_other_roots	— (added after review)	pass
#1554 (e2e: .npmrc package-lock=false and plain lockless; 2 runs + --vex)	scan::scan_nested_project_e2e::root_vendored_scan_skips_a_lockless_nested_project	npmrc=true run 1: exit 0 assertion fails (exit 1)	pass

Commands run locally:

• cargo fmt --all -- --check: clean
• cargo clippy --workspace --all-features -- -D warnings: clean
• cargo test -p socket-patch-core --lib governing_root: 45 passed
• cargo test -p socket-patch-cli --all-features --test scan scan_nested_project: 7 passed
• cargo test -p socket-patch-cli --all-features --test remedy_commands_parse: 2 passed (the new remedy commands parse)
• cargo test --workspace --all-features --no-fail-fast: all pass except 10 tests that rely on a write or remove being denied (*_write_failure_*, *_unremovable_*, repair_cleanup_failure_*, relax_loop_must_not_traverse_symlinked_root, e2e_bun_lockb::binary_shared_bundled_record_hosted_pin_is_managed). The sandbox runs as uid 0, so those denials never happen there. None of them reaches nested_npm_project or the scan nested-project path. CI runs as non-root and is the check for them.
• npm/pypi/gem wrappers: not touched, so no parallel change needed.

Bugbot

• 7ce7fcd: one finding (an unmodeled pnpm glob counted as "member", hiding nested projects). Fixed in 80868e4 with a test; the thread is resolved.
• 80868e4: one finding (the brace-glob fallback ignored pnpm's !, test and dot rules). Fixed in 121882e with a test; the thread is resolved. CI on 80868e4: 34 pass, 0 fail.
• 121882e: one low-severity finding (every leading ! was stripped). Fixed in 6f4c327; the thread is resolved.
• 6f4c327: Bugbot found no new issues. CI: 35 pass, 19 skipped, 0 fail.
• CI on 7ce7fcd: 35 pass, 50 skipped, 0 fail. That includes the root-only tests listed above.

/code-review high

I fixed every confirmed finding except two:

• Shallower locked project wins over a deeper lockless one (tools/x locked, tools/x/sub lockless): not changed. The existing 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) #1534 test pins this ("a lockless directory belongs to the nearest lock root"). In either case the copy is skipped from the root run. Only the directory the warning names differs.
• Share one ancestor-walk helper with package_json_workspace_root / vlt_workspace_root: not done. Those walks canonicalize and weigh locks, while this one is deliberately lock-agnostic and bounded at the scan root. Merging them would widen this PR into a refactor (see Tracking: derive scan candidates, lock entries and hosted refs from one project inventory instead of four discovery systems #1112).
• file: link targets: the root lock lists their copies, so they are already locked and never reach this check.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LYN2ka9heR9fMVjsgTJGfZ

---

Generated by Claude Code

---

Note

Medium Risk
Changes nested-project detection and skip/warning paths for hosted/vendored npm scans; incorrect workspace or lockless classification could skip or patch the wrong packages, though coverage is broad.

Overview
Root vendored/hosted scans no longer fail with vendor_lock_entry_not_found when a nested directory has package.json and node_modules but no lockfile (package-lock=false or npm install --no-package-lock). Those installs are skipped like nested projects with their own lock (#1534).

nested_npm_project in governing_root.rs still prefers directories with an npm-family lock (or Rush). When none match, it uses new lockless_npm_project logic: walk from the copy’s first node_modules up to the scan root, climbing to a workspace root when listing_workspace lists the path (npm/yarn/vlt/pnpm/Rush, including partial pnpm glob handling). has_own_npm_family_lock is exported for discovery warnings.

nested_project_skipped text now splits locked vs lockless nested projects: lockless warnings suggest npm install --package-lock then a targeted scan, or socket-patch scan --mode agent <dir>. Docs in ecosystems.md match.

CI pins uv 0.13.1 in ci.yml and pipenv-compatibility.yml because 0.13.2 rejects Pipenv pylocks with environments = [].

Unit tests in governing_root and e2e root_vendored_scan_skips_a_lockless_nested_project cover the behavior.

^{Reviewed by Cursor Bugbot for commit e7987ac. Configure here.}

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

Ready for review — head 6f4c327.

• CI: 35/35 checks green (19 skipped), ci-ok green. No main-wide failures.
• Bugbot: reviewed 6f4c327, no new issues. All 3 earlier threads are resolved (findings fixed in later commits).
• Mergeable against main; no CHANGELOG.md changes.
• Reviewer note: the PR description lists two /code-review findings left unchanged on purpose (nearest-lock-root precedence pinned by the 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) #1534 test; ancestor-walk helper not merged to avoid a refactor).

Slack announcement not sent this run (send unavailable); the next run retries.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[agent] The merge queue removed this PR because of e2e (ubuntu-latest, e2e_vex_build, pipenv:: --ignored, 2026.8.0) (pipenv::pipenv_pylock_projects_wire_what_pipenv_installs: uv pip install -r pylock.toml → "The target environment is not supported by the lockfile").

This PR did not cause it. The pipenv legs install whatever uv is latest, which was 0.13.1 in yesterday's passing queue run and 0.13.4 in today's. uv ≥ 0.13.2 refuses the environments = [] that Pipenv 2026.8.0 writes, so the leg fails for every PR in the queue, and main's nightly fails the same way. #1639 has the diagnosis and the fix (pin setup-uv to 0.13.1).

e7987ac merges main and ports #1639's commit (a7c9207, cherry-picked), so this PR can go back into the queue now. Once #1639 merges, the port changes nothing. Checked locally after the merge: fmt, clippy -D warnings, governing_root unit tests and scan_nested_project e2e tests all pass.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Wenxin Jiang (@Wenxin-Jiang) this changed after your approval (on 6f4c3273), so it needs another look before it goes through the merge queue.

Besides merges from main, the only new commit is e7987ac: the CI-only uv pin from #1639, byte-for-byte the same 12 added lines (version: "0.13.1" on the two setup-uv steps in ci.yml and pipenv-compatibility.yml). No crate code changed. It's there because uv 0.13.2 fails the pipenv:: e2e leg on every merge-queue entry. Once #1639 lands it does nothing.

If that's fine with you, re-approving e7987ac4 is all this needs.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[agent] The merge queue removed this PR again, this time for coverage: one test, update::swap::tests::update_lock_is_exclusive_and_released_on_drop, panicked at crates/socket-patch-core/src/update/swap.rs:467 (unwrap() on Err(InProgress), the re-acquire after drop(first)). The other 6547 core tests passed.

This PR did not cause it:

• This PR does not touch update/.
• The same code passed coverage in Fix Pipenv refusing split-version categories (#1616) #1617's queue run (39471359983), which was built on this PR's queue commit 3e58757.
• It also passed on this PR's own CI at e7987ac.

Every test that sets SOCKET_UPDATE_STATE_DIR shares #[serial(update_state_dir_env)]. The likely race: the flock is per open file description, so a child process another test spawns in parallel holds a copy of the lock fd from fork until exec (O_CLOEXEC only closes it at exec). If that child is in that window when first drops, the re-acquire still sees the lock held.

No fix exists yet. A proposed patch for a separate PR is to let the re-acquire in that test retry briefly:

let reacquired = (0..50).find_map(|_| match acquire_update_lock() {
    Err(UpdateError::InProgress) => { std::thread::sleep(std::time::Duration::from_millis(20)); None }
    other => Some(other),
});
assert!(matches!(reacquired, Some(Ok(Some(_)))), "lock must be reacquirable after release");

I am putting this PR back in the queue once. If it fails a second time, I will treat that as a real failure.

---

Generated by Claude Code

[cursor]

✅ 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 e7987ac. Configure here.}