[Mikola Lysenko (mikolalysenko)]

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

Fixes #1597

Summary

A vendored pnpm scan no longer breaks the project's build approvals.
Before this change, vendoring a package whose install script the project
approves (allowBuilds: {sp-build: true}, onlyBuiltDependencies: [sp-build]) exited 0 with no warning. The next install on pnpm 10.34.2+
silently skipped the script, and on pnpm 11/12 every frozen install failed
with ERR_PNPM_IGNORED_BUILDS until the patch was rolled back.

Vendoring now adds the same decision under the vendored key
(sp-build@file:.socket/vendor/npm/<uuid>/sp-build-1.0.0.tgz) next to
the user's entry, and revert / rollback / remove take it out again.

Root cause

Vendored pnpm wires the package through a file: override, so pnpm
installs it as name@file:<spec>. Since pnpm 11.5.3 (backported to 10.34.2), build decisions
are matched against that id: a key naming the registry package
(name, name@1.0.0) no longer applies, and only the full
name@file:<spec> key does. Nothing in the vendored pnpm path read these
settings.

A second constraint, found while reviewing: pnpm 10.20–10.34.1 and 11.0–11.5.2 refuse
a name@file: key outright (ERR_PNPM_INVALID_VERSION_UNION). Those
versions still match the vendored copy by name, so they need no key.
That means the key can only be written when we know which pnpm runs.

Measured with real pnpm and a file: tarball dependency with a
postinstall:

pnpm	name-only approval	+ name@file: key
9.15.9	built	built
10.20.0, 10.34.1, 11.5.2	built (allowBuilds)	ERR_PNPM_INVALID_VERSION_UNION
10.34.2, 10.34.7	skipped	built
11.5.3, 11.28.7, 12.15.0	ERR_PNPM_IGNORED_BUILDS	built

pnpm 11+ reads only allowBuilds; onlyBuiltDependencies,
ignoredBuiltDependencies and neverBuiltDependencies are ignored there
whether or not the package is vendored.

Fix

New module vendor/pnpm_build_approvals.rs, called from the pnpm (lock
9.0) wiring step:

• Reads the user's decision for the package from pnpm-workspace.yaml
  (allowBuilds: block map, onlyBuiltDependencies: block list,
  column-0 items included) and package.json#pnpm (same two fields). A
  pinned name@x || y key beats a name-only one.
• Writes the vendored key with the same true/false decision right
  after the user's entry, only when every parseable pnpm pin
  (packageManager, devEngines, engines.pnpm,
  node_modules/.modules.yaml) admits only 10.34.2+ (within 10.x),
  11.5.3+ (within 11.x) or 12+. A pin admitting only older pnpm needs
  nothing; a range crossing a threshold (^11.0.0) counts as unknown. Without a usable pin, nothing
  is written and vendor_pnpm_build_approval_lost names the key to add.
• Replaces a key a superseded patch (older uuid, same name@version)
  left, carrying its decision when it's the only one. An added key
  follows the user's decision on re-runs when it flips.
• A flow-style value ([pkg], multi-line too) or a non-boolean
  allowBuilds value is left alone with the same warning.
• Each added key is a ledger wiring record (pnpm_ws_allow_build,
  pnpm_ws_only_built, pnpm_pkg_allow_build, pnpm_pkg_only_built)
  that revert removes; the workspace file and package.json byte-restore.
• Legacy pnpm 7/8 locks are untouched (those match by name).

The version gate lives in formats/pnpm/version.rs
(matches_file_id_build_keys), which now reads pins at patch precision.

Docs: CLI_CONTRACT.md warning table, docs/ecosystems.md pnpm notes.
No wrapper (npm/, pypi/, gem/) change is needed: they only
dispatch the binary.

Test evidence

Case	Test	Without fix	With fix
#1597 allowBuilds true/false, workspace file, revert byte-exact (P1 fixture: transitive consumer copy too)	pnpm_lock::tests::ws_build_approval_is_carried_to_the_vendored_key_and_reverted	FAILED	ok
#1597 package.json pnpm.onlyBuiltDependencies (pnpm 10)	pnpm_lock::tests::package_json_only_built_approval_is_carried_and_reverted	FAILED	ok
superseding patch replaces the old key, revert restores	pnpm_lock::tests::superseding_patch_replaces_the_older_vendored_approval_key	FAILED	ok
flow value warns with the key	pnpm_lock::tests::inline_build_approval_warns_with_the_key_to_add	FAILED	ok
pnpm 10.30 pin: no key; no pin: warning, no key	pnpm_lock::tests::build_approval_key_is_written_only_for_a_pnpm_that_reads_it	n/a (new gate)	ok
real pnpm 11.28.7 and 11.5.3 (allowBuilds), 10.34.7 (onlyBuiltDependencies), 10.30.0 and 11.5.2 (no key): fresh frozen offline install lands patched bytes AND runs the approved postinstall; revert byte-restores	e2e_vendor_pnpm_build::pnpm_vendor_keeps_approved_build_scripts_running	FAILED (no key)	ok
matcher, pinned/name precedence, column-0 lists, scoped quoting, flipped decision, flow/anchor/null values, substring names, package.json order, revert	pnpm_build_approvals::tests (13)	n/a	ok
version gate at 10.34.2 / 11.5.3 (11.0–11.5.2 excluded, from review)	formats::pnpm::version::tests::file_id_build_keys_start_at_10_34_2_and_11_5_3; e2e 11.5.2 leg fails on the old gate	n/a	ok

Locally (Linux): cargo fmt --all -- --check ok,
cargo clippy --workspace --all-features -- -D warnings ok,
full cargo test --workspace --all-features --no-fail-fast: 14689
passed, 10 failed, none in pnpm code. Nine are write-failure tests that
use chmod and can't fail when run as root (this container runs as uid 0):
copy_tree symlinked root, vlt_heal unremovable lock, pypi_poetry /
pypi_requirements wire failures, three in_process_redirect
write-failure cases and two repair cleanup failures. The tenth is
e2e_bun_lockb::binary_shared_bundled_record_hosted_pin_is_managed, which
needs to reach patches-api.socket.dev (blocked by this sandbox's proxy).
CI runs all of them unprivileged with network.

/code-review high

Fixed: version gate (finding 1, the largest: confirmed on real pnpm),
multi-line flow values and substring matching (3, 6), flipped decision
sync (4), non-boolean / anchored values (7), package.json key placement
(8), duplicated selection logic and repeated path parsing (10).

Not fixed, with reasons:

• ignoredBuiltDependencies / neverBuiltDependencies (2): pnpm 10
  still matches those by name for the vendored copy (measured: 10.34.7
  with strictDepBuilds exits 0), and pnpm 11+ does not read them at
  all, vendored or not, so there is no decision to carry.
• A hand-written stale name@file: key for another uuid is removed
  without a record (5): it names a superseded patch's artifact, which the
  supersede deletes, so the key is dead; restoring it on revert would only
  re-add a key pointing at nothing.
• A shared YAML block-sequence reader with package_globs (9): that
  reader also handles flow values and returns globs for a different
  caller; merging them is a separate refactor.

https://claude.ai/code/session_01NDKy3guPS8y9iNNhPQGyR2

---

Note

Medium Risk
Changes vendored pnpm workspace/package.json wiring and install-script behavior; version-gated with revert ledger records and warnings for ambiguous cases.

Overview
Fixes #1597: vendored pnpm no longer drops build script approvals when a package is wired as name@file:.socket/vendor/....

On pnpm 10.34.2+ / 11.5.3+, allowBuilds and onlyBuiltDependencies match the installed id, so name-only keys stopped applying after vendoring (skipped scripts on 10, ERR_PNPM_IGNORED_BUILDS on 11+). Vendoring now mirrors the same decision under the vendored key in pnpm-workspace.yaml and package.json#pnpm, records it in the wiring ledger, and revert/rollback removes those entries. A new matches_file_id_build_keys gate in formats/pnpm/version.rs only writes the file: key when project pins say pnpm needs it; older pnpm (or unparseable pins / flow-style values) get vendor_pnpm_build_approval_lost instead of a silent break.

Docs (CLI_CONTRACT.md, docs/ecosystems.md) and unit/e2e tests cover carry, revert, superseded keys, and real pnpm installs.

^{Reviewed by Cursor Bugbot for commit 7e1a1ae. Configure here.}

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

Burn-down agent: labeled Ready for review at 4e0cb53.

• CI: 86/86 settled green on 4e0cb53 (36 success, 50 skipped).
• Merges cleanly with main (13 commits behind, no conflicts; not merging main in to avoid needless CI).
• Bugbot: reviewed 4e0cb53, no findings.
• Reviewer focus: vendor/pnpm_build_approvals.rs — the pnpm-version gate (key written only when every pin admits nothing older than 10.34.2, since 10.20–10.34.1 reject name@file: keys).
• Slack announcement not sent this run (Slack send tool unavailable); the next run should retry.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

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

[Mikola Lysenko (mikolalysenko)]

Burn-down agent: Ready for review re-confirmed at new head 7e1a1ae (label kept).

• CI: 53/53 settled green on 7e1a1ae (34 success, 19 skipped). Merges cleanly with main.
• Bugbot: reviewed 7e1a1ae, no new issues. The earlier review thread on the pnpm 11.x gate is resolved.
• Reviewer focus: the per-major pnpm version gate for vendored build keys (10.34.2+, 11.5.3+, 12+) in crates/socket-patch-core/src/formats/pnpm/version.rs and vendor/pnpm_build_approvals.rs.
• Slack announcement not sent this run (Slack send tool unavailable); the next run should retry.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Final review brief

What it does. When a vendored pnpm scan rewires a package to name@file:.socket/vendor/npm/<uuid>/…, pnpm 10.34.2+ / 11.5.3+ stop matching the project's allowBuilds / onlyBuiltDependencies decision (keyed by name), so pnpm 10 skips the install script and pnpm 11/12 fail every install with ERR_PNPM_IGNORED_BUILDS. This PR copies the user's decision to the vendored key beside their entry (workspace file or package.json#pnpm), records it in the ledger, and removes it on revert. It writes the key only when the pnpm pins say a version that accepts it; otherwise it warns with vendor_pnpm_build_approval_lost (fixes #1597).

Risk: low–medium. The change only touches the vendored pnpm v9 path and never edits the user's own entries. The riskiest part is the version gate: older pnpm (10.20–10.34.1, 11.0–11.5.2) rejects a file: key. A wrong gate would break installs, which is why an unpinned project gets a warning and no edit.

Look here

• formats/pnpm/version.rs:45: matches_file_ids, the per-major gate. Ranges decide only when both ends agree within one major (L186).
• vendor/pnpm_build_approvals.rs:170:`` carry. It does nothing on old pnpm, edits on new pnpm, and only warns when the version is unknown.
• vendor/pnpm_build_approvals.rs:398:``` carry_ws, the line surgery on `pnpm-workspace.yaml` (CRLF kept, stale keys from a superseded uuid dropped).
• vendor/pnpm_lock.rs:333 and :1240: hooks into wiring and revert.

Verified

• Read the full diff (8 files, +1460/−36). Traced the select/anchor/stale index logic for both the YAML and JSON surfaces, the CRLF handling, and that revert works when only approval records exist.
• Tanmay's 11.0–11.5.2 finding is fixed in 7e1a1ae, with unit cases for 11.0.0, 11.2.0 and 11.5.2. Its thread is resolved.
• cargo test -p socket-patch-core --lib pnpm passes locally (453 tests).
• CI on 7e1a1ae: 35 checks passed and 19 skipped, none failed. ci-ok and clippy are green. Bugbot passed with no new issues.
• CHANGELOG.md is untouched. No unresolved threads.

Changes I made. None.

Open questions. None blocking. Nit: a prerelease such as 11.5.3-rc.1 counts as 11.5.3. That is harmless in practice.

Auto-merge (squash) is armed, so approving sends this straight to the merge queue.

---

Generated by Claude Code