GeezerVison

Assisted-by: Claude Code:claude-opus-5-5

A hosted scan or get run from a member of an npm, yarn (classic or
berry) or Bun workspace found the member's copy of a patched package,
saw no lockfile in the member directory, pinned nothing and exited 0
with "success". The package manager then installed the unpatched copy
from the workspace root's lockfile, and the only hint was a warning
about a missing package-lock.json.

The workspace-member pre-check only knew about pnpm and cargo. It now
also finds the nearest ancestor package.json whose "workspaces" list
matches the member directory. If that root holds a package-lock.json,
npm-shrinkwrap.json, yarn.lock, bun.lock or bun.lockb, the run is
refused before anything is written with
redirect_workspace_lockfile_elsewhere, and the message names the
workspace root to run from. Vendored mode already refused this layout.

Fixes #884

Assisted-by: Claude Code:claude-opus-5-5

main has failed socket-patch-core's lib tests since Gradle support
(#646) and the digest helpers (#865) both landed. The guard test
production_digests_go_through_the_helpers flags three files #646 added
that still hash inline: crawlers/gradle_cache.rs, patch/jvm_jar.rs and
patch/sidecars/maven.rs. That breaks test, test-release and coverage on
every open PR.

Each inline sha1/sha256 call now goes through sha1_hex_of or
sha256_hex_of, which compute the same lowercase hex. Behaviour is
unchanged.

Assisted-by: Claude Code:claude-opus-5-5

cursor Bot left a comment •

edited

Loading

Uh oh!

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

A workspace root with no lockfile of its own can itself be a member of
an outer workspace (yarn berry's nested worktrees), where the outer
root holds the lockfile both use. The member check stopped at the inner
root and let the hosted run report success with nothing pinned. It now
keeps walking with the inner root as the member and refuses at the
outer root.

Refs #884

Assisted-by: Claude Code:claude-opus-5-5

cursor Bot left a comment •

edited

Loading

Uh oh!

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

A pnpm workspace nested inside an outer yarn or npm workspace owns its
members: pnpm installs them from the nested pnpm-lock.yaml. The member
walk treated that nested root as lockless and went on to the outer
root, so the refusal named the wrong directory to run from. The walk
now stops at a root holding any npm-family lock (pnpm, vlt, Rush) and
leaves it to the pnpm check, which names the right root.

Refs #884

Assisted-by: Claude Code:claude-opus-5-5

cursor Bot left a comment •

edited

Loading

Uh oh!

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

The previous change stopped the member walk at a nested root holding a
pnpm, vlt or shrinkwrap.yaml lock and left it to the pnpm check. That
check only knows pnpm workspaces with pnpm-workspace.yaml or
lockfile-dir, so a stray pnpm-lock.yaml there could still let a hosted
run from the member report success with nothing pinned.

The pnpm check now runs first, so a pnpm workspace still gets its own
precise message. The package.json walk then refuses at the first
matching root that holds any npm-family lock, naming that root. Only a
Rush root, whose locks live under common/config, ends the walk without
a refusal.

Refs #884

Assisted-by: Claude Code:claude-opus-5-5

cursor Bot left a comment •

edited

Loading

Uh oh!

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

When a yarn or npm workspace sits inside a pnpm workspace, the member's
lockfile is the nearer one. The pnpm check ran first and named the outer
pnpm root, so a follow-up run from there would rewrite pnpm-lock.yaml
and leave the member's real lockfile unpatched.

The member check now weighs both roots and names the nearer one. When
they are the same directory, pnpm's own message wins.

Refs #884

Assisted-by: Claude Code:claude-opus-5-5

cursor Bot left a comment •

edited

Loading

Uh oh!

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

pnpm reads only pnpm-workspace.yaml and vlt only vlt.json, so a pnpm or
vlt lock sitting at a package.json "workspaces" root does not govern
that root's members. Counting such a stray lock as ownership let it
beat the outer pnpm workspace that really installs the member, and the
refusal pointed at a directory whose run would rewrite the wrong
lockfile.

The workspaces walk now counts only npm, yarn and Bun locks. Roots that
pnpm governs are left to the pnpm check, and when both kinds govern a
member the nearer root still wins.

Refs #884

Assisted-by: Claude Code:claude-opus-5-5

cursor Bot left a comment •

edited

Loading

Uh oh!

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

f92cb6a ran a workspace-wide cargo fmt, reformatting 118 files that the
fix does not otherwise touch. That buried the real change in ~2,300
lines of formatting diff and invites merge conflicts with every other
open PR. Restore those files to their merge-base versions; each was
checked to be rustfmt-equivalent to its main version, so behavior is
unchanged.

Co-Authored-By: Claude <[email protected]>

cursor Bot left a comment

Main's #888 added the pnpm settings-elsewhere refusal next to the
workspace-member checks this branch adds. Both checks are kept: the
package.json workspace refusal runs after the pnpm lock check, then the
trustLockfile settings refusal. The CLI contract row and the CLI tests
from both sides are kept, and the new unit tests pass the trust flag
that refusal() takes now.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01LYxnnBSxyMahcBX9SZag9L