Fix pnpm 11 env booleans other than true/false (#1557)

[Mikola Lysenko (mikolalysenko)]

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

Fixes #1557

Summary

A hosted pnpm 11/12 scan run with pnpm_config_trust_lockfile (or
PNPM_CONFIG_TRUST_LOCKFILE) set to an empty string, null or
undefined now writes trustLockfile: true as if the variable were
unset, and its warning no longer claims the variable was respected. The
next frozen install in that environment succeeds. An empty variable is a
normal CI shape: env: X: ${{ vars.Y }} with the repo variable unset.

Root cause

#1533 (the #1514 fix) parsed pnpm 11+'s pnpm_config_* variables with
the npm/.npmrc coercion in PnpmSetting::as_bool, where "",
null and undefined mean false. pnpm 11 doesn't do that. Measured
with pnpm config get on pnpm 11.28.5, a pnpm_config_<bool> variable
counts only when it is exactly true or false. Any other value
(empty, null, undefined, 0, FALSE, false, yes) is ignored
in favour of pnpm-workspace.yaml, for every key I probed: trust-lockfile,
lockfile, shared-workspace-lockfile and git-branch-lockfile.

The fix is in the shared lookup env_setting
(utils/pnpm_workspace.rs). The pnpm_config_ family, plus the
uppercase trust spelling, goes through one helper, pnpm_env_setting,
that keeps only true or false. Both trust call sites
(hosted/engine.rs pnpm_trust_env_override and scan/hosted.rs
trust_env_off, the member governing-root refusal) pick this up. So do
lockfile_disabled and the sharedWorkspaceLockfile and
gitBranchLockfile env fallbacks. The npm_config_ family that pnpm 10
and older read keeps its existing coercion.

The first commit filtered only the trust variable. /code-review high
pointed out that the same wrong parse applies to the other
pnpm_config_* keys, and the pnpm 11 probe confirmed it, so the second
commit moved the rule to the shared boundary.

Review follow-up: pnpm 12 trims the value before matching (" false" and "false " are false; measured on pnpm 12.11.2), while pnpm 11 doesn't. pnpm_env_setting therefore trims unless the project is on pnpm 11, and also trims when the major is unknown (the pre-PR behaviour). A PADDED table in the unit test covers both majors. Bugbot follow-up: the hosted member preflight (scan/hosted.rs) now reads the variable at the project's pnpm major through trust_lockfile_env_for, so it agrees with the rewrite (test the_trust_variable_follows_the_project_pnpm_major).

Two existing assertions changed to match measured pnpm behaviour:

• The Hosted pnpm 11/12 scan ignores a pnpm_config_trust_lockfile=false env override and says "installs need no extra flags", but the next frozen install fails with ERR_PNPM_TARBALL_URL_MISMATCH #1514 unit test's uppercase " false " (padded) is now "false",
  because that test loops over pnpm 11, where the padded form is ignored.
  The padded cases moved to the new PADDED table.
• The precedence test's pnpm_config_git_branch_lockfile=TRUE is now
  true. The test is about pnpm-over-npm precedence, and pnpm ignores
  TRUE.

Test evidence

Red without the fix, green with it:

• utils::pnpm_workspace::tests::a_pnpm_config_variable_counts_only_as_true_or_false (unit; it started as an_empty_or_null_trust_lockfile_variable_sets_nothing, which was red before the fix)
• hosted::engine::tests::issue_1557_an_empty_trust_lockfile_variable_keeps_the_write: red without the fix (no pnpm-workspace.yaml written), green with it
• e2e_redirect_pnpm_build::pnpm11_empty_trust_lockfile_env_is_ignored (real pnpm 11.28.5, dead registry): red without the fix at "an empty variable pnpm ignores must not stop the write". Green with it: the scan writes the key, and a fresh pnpm install --frozen-lockfile run with pnpm_config_trust_lockfile= installs the patched bytes.

Ran locally:

• cargo fmt --all -- --check: ok
• cargo clippy --workspace --all-features -- -D warnings: ok
• cargo test -p socket-patch-cli --all-features --test e2e_redirect_pnpm_build -- --ignored --skip pnpm_pinned_matrix: 11 passed, including Hosted pnpm 11/12 scan ignores a pnpm_config_trust_lockfile=false env override and says "installs need no extra flags", but the next frozen install fails with ERR_PNPM_TARBALL_URL_MISMATCH #1514's pnpm11_trust_lockfile_env_override_is_respected
• in_process_redirect_pnpm 38, hosted_memory_engine 43, hosted_memory_parity 42, scan 244: all passed
• cargo test --workspace --all-features --no-fail-fast: everything passes except 10 tests in 4 targets that fail in this sandbox for reasons outside this diff. 9 are chmod-based write-failure tests, which can't fail a write when run as root (copy_tree symlinked root, vlt_heal unremovable lock, pypi_poetry/pypi_requirements wire write failure, in_process_redirect write-failure ×3, repair cleanup ×2). The 10th, e2e_bun_lockb::binary_shared_bundled_record_hosted_pin_is_managed, tries to reach patches-api.socket.dev, which the sandbox blocks. None of them touch pnpm env parsing; CI is authoritative.

Per-issue checklist

• Hosted pnpm 11/12 scan treats an empty (or null/undefined) pnpm_config_trust_lockfile as false and skips the trustLockfile config, so the next frozen install fails #1557, empty / null / undefined pnpm_config_trust_lockfile (both cases): unit, engine and real-pnpm e2e tests above. The member-refusal predicate in scan/hosted.rs uses the same trust_lockfile_env, which the unit test covers.

Follow-ups

• None.

No wrapper (npm/, pypi/, gem/) changes are needed; this is Rust-only parsing.

🤖 Generated with Claude Code

https://claude.ai/code/session_014yr5aboMV1HKW9nDgrD6GP

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

Ready for review at 9b470d4.

• CI: 36/36 run checks green, 50 skipped by path filters (86 total); no main-wide failures.
• Bugbot: reviewed 9b470d4, no findings.
• Mergeable, no conflicts; CHANGELOG.md untouched.
• Worth a look: the shared pnpm_env_setting now keeps only exact true/false for every pnpm_config_* key (not just trust-lockfile), and two existing assertions changed to match measured pnpm 11 behaviour.

Slack announcement not sent this run (Slack send isn't available to the burn-down agent); the next run will retry.

---

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 45721dd. Configure here.}