GeezerVison

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

Fixes #1460

Summary

Hosted pnpm mode refused to pin a lock over environment settings the project's pnpm never reads. The common trigger is npx socket-patch scan --mode hosted in a pnpm 11/12 project whose .npmrc still has an npm-era package-lock=false. npx exports npm_config_package_lock=, and pnpm 12 ignores it and installs from the lock. The scan still warned redirect_pnpm_lockfile_disabled, pinned nothing, and exited 0 with status: success.

Root cause

env_setting (crates/socket-patch-core/src/utils/pnpm_workspace.rs) looked up pnpm_config_<key> and then npm_config_<key> on every pnpm major. Real pnpm reads one family per major: npm_config_* on pnpm 10 and older, pnpm_config_* on pnpm 11 and newer (empirical table in #1460). This affected three settings:

• lockfile / package-lock (lockfile_disabled): false redirect_pnpm_lockfile_disabled
• git-branch-lockfile (view_setting via git_branch_locks, used by both hosted and vendored): false redirect_pnpm_git_branch_lockfile / vendor_pnpm_git_branch_lockfile
• shared-workspace-lockfile (view_setting via workspace_members): member locks routed by a variable pnpm ignores

Fix

env_setting takes the pnpm major, the same pnpm_major that already chooses pnpm-workspace.yaml vs .npmrc. It reads pnpm_config_* for 11+, npm_config_* for 10 and older, and both when the major is unknown (the safe side, same as the file rule). view_setting is now async and passes the major down. The major is only computed when a candidate variable is actually set, so scans with no such variable don't re-read the lock. CLI_CONTRACT.md now describes the per-major family for all three settings.

Tests (red → green)

Local runs:

• cargo fmt --all -- --check: ok
• cargo clippy --workspace --all-features -- -D warnings: ok
• cargo test -p socket-patch-core --all-features --lib: 6409 passed. The 4 failures (copy_tree symlink relax, vlt_heal unremovable lock, pypi_poetry/pypi_requirements write-failure) depend on chmod and fail only because the sandbox runs as root. None touch pnpm.
• cargo test -p socket-patch-cli --all-features --test in_process_redirect_pnpm --test in_process_vendor_pnpm_takeover --test hosted_memory_parity: 33 + 15 + 42 passed
• The full cargo test --workspace ran out of sandbox disk while linking ~100 CLI test binaries, so CI is the full run.

No wrapper (npm/, pypi/, gem/) changes are needed: this logic lives only in the Rust core.

/code-review high: findings not fixed

• pnpm 10 may honor pnpm_config_*: false positive. Hosted pnpm scan refuses with redirect_pnpm_lockfile_disabled over env lockfile settings the project's pnpm major ignores (e.g. any pnpm 11/12 project run through npm exec with package-lock=false) #1460's table shows pnpm 9.15.9 and 10.34.6 installing from the lock with pnpm_config_lockfile=false set.
• A workspace member has no major of its own, so both families count: unchanged from before and on the safe (refusing) side. A follow-up could use the governing root's major.
• .npmrc git-branch-lockfile/shared-workspace-lockfile read on pnpm 11+, env overriding a file setting, stale .modules.yaml major, upper-case NPM_CONFIG_*: pre-existing behavior of the file and lookup rules, not this root cause. Left for separate issues.
• Fixed: the redundant pnpm_major read when no variable is set, the stale sharedWorkspaceLockfile contract line, and the duplicated test helpers.

🤖 Generated with Claude Code

https://claude.ai/code/session_01E552fKgtx93unKJDowBuF4

Generated by Claude Code