Fix pnpm trustLockfile env override ignored (#1514)

[Mikola Lysenko (mikolalysenko)]

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

Fixes #1514

Summary

On pnpm 11 and 12, a pnpm_config_trust_lockfile (or PNPM_CONFIG_TRUST_LOCKFILE) environment variable takes precedence over the trustLockfile: true that hosted mode writes into pnpm-workspace.yaml. If that variable was false, scan --mode hosted still wrote the key and reported "installs need no extra flags", and then every install in that environment failed with ERR_PNPM_TARBALL_URL_MISMATCH.

The scan now treats a non-true value of that variable as an explicit user setting, the same way it treats trustLockfile: false in the file and the way the npm arm treats npm_config_allow_remote. It writes nothing. The redirect_pnpm_trust_lockfile warning names the variable and gives the remedies: unset it, set it to true wherever the project installs, or re-run with --mode vendored.

Root cause

The trust plan in pnpm_trust (crates/socket-patch-core/src/hosted/engine.rs) chose between write, AlreadyTrue and UserSet by looking only at the text of pnpm-workspace.yaml. It never read the environment that pnpm 11+ reads ahead of that file.

Changes

• utils/pnpm_workspace.rs: new trust_lockfile_env(major, env). It returns the override only for pnpm 11 and newer, or when the major is unknown. pnpm 10 never verifies lock URLs, and no pnpm reads npm_config_trust_lockfile. The variable lookup goes through the existing env_setting. The pnpm-major heuristic is now one sync helper, pnpm_major_from, shared with the 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 lockfile check.
• hosted/engine.rs: new RewriteOptions::pnpm_env, an injected environment lookup. The CLI passes the process env. The in-memory engine passes none, since it sees no install environment. pnpm_trust respects an override in both the root-workspace branch and the member-lock branch (Hosted scan from a pnpm 11/12 workspace member with its own lock writes trustLockfile into a nested member pnpm-workspace.yaml that pnpm ignores, so the root install fails with ERR_PNPM_TARBALL_URL_MISMATCH #880). The more specific pnpm 9.0–10.4 pin and keyless-members guidance still comes first.
• scan/hosted.rs: the member pre-check (redirect_pnpm_settings_elsewhere) no longer refuses with advice to add trustLockfile: true to the root file when the environment overrides that key. In that case the engine pins the member lock and reports the variable.
• Docs: CLI_CONTRACT.md (pnpm trust contract) and docs/ecosystems.md.

Test evidence

Issue	Regression test	Red without fix	Green with fix
#1514	hosted::engine::tests::issue_1514_a_trust_lockfile_env_override_is_respected (lowercase and uppercase variable, existing trustLockfile: true, member lock; controls: true, npm spelling, pnpm 10 pin)	failed: ["pnpm-lock.yaml", "pnpm-workspace.yaml"] written	ok
#1514	utils::pnpm_workspace::tests::the_environment_sets_trust_lockfile_only_for_pnpm_11_and_newer	n/a (new API)	ok
#1514	e2e e2e_redirect_pnpm_build::pnpm11_trust_lockfile_env_override_is_respected (real pnpm 11.28.5, SOCKET_PATCH_PNPM_E2E_REQUIRED=1)	failed: rewrittenFiles: ["pnpm-workspace.yaml"], "installs need no extra flags"	ok; control re-run without the variable heals the key

Run locally:

• cargo fmt --all -- --check: ok
• cargo clippy --workspace --all-features -- -D warnings: ok
• cargo test -p socket-patch-core --all-features --lib: 6484 passed. 4 failed, all of them read-only-permission tests (copy_tree::relax_loop_must_not_traverse_symlinked_root, vlt_heal::an_unremovable_hidden_lock_keeps_every_store_entry, pypi_poetry::wire_write_failure_maps_error_and_leaves_lock_untouched, pypi_requirements::wire_failure_rolls_back_already_written_files). They can't fail as root, which is how the sandbox runs, and they are unrelated to this diff.
• cargo test -p socket-patch-cli --all-features --lib --bins: 920 passed
• e2e_redirect_pnpm_build -- --ignored pnpm11_: 4 passed
• The full cargo test --workspace build ran out of sandbox disk while linking the CLI integration binaries. CI covers those.
• No wrapper (npm/, pypi/, gem/) changes are needed: this is engine-only.

Review findings not fixed (/code-review high)

• pnpm_config_trust_lockfile=0 coercion. The value is read with the repo's existing env convention (PnpmSetting::as_bool, the npm-config reader: only ''/false/null/undefined are false), the same as every other pnpm env setting here. Changing that convention for one key would make them disagree.
• Uppercase spelling. 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 verified that PNPM_CONFIG_TRUST_LOCKFILE=false makes pnpm 12.11.2 fail on Linux, so it is honoured.
• A developer's shell env decides a committed file. This matches the npm npm_config_allow_remote precedent (CLI_CONTRACT), and the warning says plainly that nothing was written and why.
• Injected env vs std::env in view_setting. The injection keeps the engine testable and lets the in-memory engine opt out. Moving lockfile/gitBranchLockfile onto it is a separate refactor.

🤖 Generated with Claude Code

https://claude.ai/code/session_018Vu8yCCshtPxwd4jscWRAU

---

Generated by Claude Code

[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 2dc1100. Configure here.}

[Mikola Lysenko (mikolalysenko)]

Final reviewer: sent to the merge queue (squash). Approved by Tanmay Singla (@Tanmay182003) on the current head 2dc1100, ci-ok and clippy green, no unresolved review threads, no blocking labels.

---

Generated by Claude Code