Fix workspace member globs for yarn 1 and npm (#1097)

[Mikola Lysenko (mikolalysenko)]

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

Fixes #1097

Summary

A hosted scan / get from a workspace member must refuse with
redirect_workspace_lockfile_elsewhere, because the member installs from
the root's lock. The member check read every root's package.json
workspaces like npm does. It now reads them the way the package manager
that owns the root's lock does.

Root cause

workspaces_include (utils/workspace_globs.rs, called from
hosted/governing_root.rs) applied npm's last-match-wins ! negation
and had no extglobs, for every lock. I probed it on this box:

pattern	npm 10.9	yarn 1.22.22	yarn 4.10	Bun 1.4.2	Bun 1.2.23
["packages/*","!packages/b"]	a	a,b	a	a	a,b
["!packages/b","packages/*"]	a,b	a,b	a	a,b	a,b
["packages/@(a|b)"]	a,b	a,b	a,b	install error	install error
["!(internal)"]	none	none	tools (extglob)	—	—

So under a yarn classic (or pre-1.3 Bun) root, a !-excluded member was
dropped. Under npm/yarn roots, an extglob matched nothing. Either way the
refusal never fired, and the run reported success with nothing pinned.

Fix

• WorkspacesDialect describes how each manager reads workspaces:
  negation is last-match-wins (npm, Bun 1.3+, vlt), unordered (yarn
  berry, where a leading !( is an extglob), or ignored (yarn classic,
  Bun < 1.3). Extglobs are on for npm and yarn only.
• The dialect comes from the root's lock. yarn classic vs berry uses the
  shared is_berry_lock sniff. Bun 1.3+ is detected by the top-level
  configVersion it writes into bun.lock (1.2.23 writes none, and 1.4
  adds configVersion: 0 when it rewrites an older lock). Only the head
  of the lock is read.
• Only the locks whose manager lists the member govern it. The refusal
  names just those, and the stray-member-lock check (Hosted and vendored scans run from an npm workspace member that has a stray package-lock.json of its own rewrite that lock, which npm ignores, and report success while npm installs the unpatched package and VEX attests not_affected #1094/Hosted and vendored scans from a Bun workspace member with a stray bun.lock / bun.lockb pin that ignored lock, exit 0, and lock-only VEX attests not_affected while Bun installs the unpatched package #1101/Hosted and vendored scans from a vlt workspace member with a stray vlt-lock.json write to that lock, which vlt ignores, and exit 0 (vendored VEX then attests not_affected while vlt ci fails) #1134)
  no longer calls a member's own lock stray when its own manager
  excludes the member. A lockless intermediate root lists a member when
  any dialect does.
• Extglob matching (@ ? * + !, nested, minimatch's !(..)rest
  semantics) is memoized, so ambiguous groups stay polynomial.
• CLI_CONTRACT.md documents the per-manager grammar.

Bun < 1.3 (from the issue comments) is covered: a bun.lock without
configVersion, or a bun.lockb alone, ignores negation.

Changed test: package_json_workspace_non_members_are_left_alone
asserted that an empty yarn.lock root drops a !-negated directory.
That is the #1097 bug for yarn classic, so the test now uses a berry lock
for that assertion. Berry really does drop the directory.

Test evidence

• New e2e in_process_redirect_pnpm::hosted_run_from_negated_or_extglob_workspace_member_refuses
  (scan and get; yarn classic / old Bun / bun.lockb negation, npm,
  shrinkwrap, classic and berry extglobs). Red on main 15c2c83: the
  first case reports "status":"success" with redirect_unconfirmed.
  Green on d7b844c.
• New unit tests: workspace_globs::{extglob_dialects_match_like_npm_and_yarn, negation_is_per_dialect, ambiguous_extglobs_stay_fast} and
  governing_root::{package_json_workspaces_read_in_the_root_locks_dialect, lockless_intermediate_root_reads_the_widest_dialect, only_the_locks_whose_manager_lists_the_member_govern_it, bun_config_version_is_read_at_the_top_level_only}.
• cargo fmt --all -- --check: clean. cargo clippy --workspace --all-features -- -D warnings: clean.
• cargo test --workspace --all-features: 14345 passed, 13 failed. All
  13 are environmental. 12 are write-failure / unremovable-file tests
  that can't fail as root (this sandbox runs as uid 0), and
  e2e_bun_lockb::binary_shared_bundled_record_hosted_pin_is_managed
  needs network to patches-api.socket.dev. None of them touch the changed
  code. CI is the arbiter.
• No wrapper changes are needed: the logic lives in core only.

Per-issue checklist

• Hosted scan from a yarn classic workspace member still pins nothing and exits 0 when the root's workspaces use a ! pattern (yarn 1 ignores it) or an extglob like packages/@(a|b) #1097 ! half (yarn classic, Bun < 1.3): e2e + package_json_workspaces_read_in_the_root_locks_dialect
• Hosted scan from a yarn classic workspace member still pins nothing and exits 0 when the root's workspaces use a ! pattern (yarn 1 ignores it) or an extglob like packages/@(a|b) #1097 extglob half (yarn and npm, per the comments): e2e + extglob_dialects_match_like_npm_and_yarn
• Hosted scan from a yarn classic workspace member still pins nothing and exits 0 when the root's workspaces use a ! pattern (yarn 1 ignores it) or an extglob like packages/@(a|b) #1097 get entry point (comment): e2e covers get

Bugbot (d7b844c) found 1 issue, the lock head read bypassing the FIFO-safe opener. Fixed in bfa67a3 with a test.

/code-review high ran on d9d05fd. All 9 findings were fixed in d7b844c:
lock filtering (3), berry negation order and !(, extglob blowup, head-only
lock reads, reuse of is_berry_lock, top-level configVersion, and a
?() simplification.

Follow-up, out of scope: npm_crawler's workspace directory expansion
still has no extglob support.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FkKQZyi8RSQAgn4DdJc2DP

---

Generated by Claude Code

[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]

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