Vendored pnpm with two or more packages: vendor --revert and rollback leave an empty pnpm.overrides in package.json and (lockfile 9.0) a scaffolded pnpm-workspace.yaml behind

[agent] Found by the scheduled pnpm bug-hunt routine (ledger #303).

Summary

On a pnpm project with no pnpm.overrides and no pnpm-workspace.yaml, vendoring two or more packages and then running vendor --revert (or rollback) restores pnpm-lock.yaml byte-exactly. But it leaves "pnpm": { "overrides": {} } in package.json. On a lockfile 9.0 project (pnpm 9–12) it also leaves a pnpm-workspace.yaml that vendoring created (packages: ['.'] plus an empty overrides: key). With exactly one vendored package the revert is byte-exact. Release 4.0.0 is byte-exact with two packages too, so this is a regression.

Impact

After a full revert the checkout isn't back to its pre-vendor state. Two tracked files are dirty (one of them new) and need a manual cleanup commit. The leftover pnpm-workspace.yaml also turns a single-package project into a workspace root as far as pnpm is concerned. Frozen installs still pass and the lock is untouched, so this isn't a supply-chain break. It's a "revert leaves residue" bug: the contract for vendor --revert is to "restore recorded original lockfile fragments", and the backend tracks createdPnpmTable / createdOverridesTable / createdWorkspaceFile precisely so that it can delete what it created.

Repro (main `045d7ec`, Linux, Node 22)

mkdir app && cd app
cat > package.json <<'EOF'
{
  "name": "fx",
  "version": "1.0.0",
  "private": true,
  "dependencies": {
    "left-pad": "1.3.0",
    "is-number": "7.0.0"
  }
}
EOF
pnpm install                      # pnpm 12.8.1
# stage .socket/manifest.json + blobs with patches for both packages
socket-patch vendor --json        # success, applied 2
socket-patch vendor --revert --json   # success
git diff / ls                     # see below

The result after the revert (pnpm 12.8.1; pnpm-lock.yaml is byte-identical to the original):

--- package.json (original)
+++ package.json (after vendor --revert)
@@
     "is-number": "7.0.0"
+  },
+  "pnpm": {
+    "overrides": {}
   }
 }
--- /dev/null
+++ pnpm-workspace.yaml
+packages:
+  - '.'
+overrides:

socket-patch rollback gives the same result. On pnpm 7/8 (legacy 5.4 / 6.0 locks) only the package.json residue appears, because the legacy dialect doesn't mirror overrides into a workspace file.

Why

The ledger records the "created" flags only on the entry that was vendored first (.socket/vendor/state.json):

pkg:npm/is-number@7.0.0  pnpm: {createdOverridesTable: true, createdPnpmTable: true, createdWorkspaceFile: true}
pkg:npm/left-pad@1.3.0   pnpm: {}

The revert then processes entries in that same order (is-number, then left-pad). When the creator entry is reverted, left-pad's key still keeps the table and the workspace file non-empty, so nothing is removed. When left-pad is reverted last and empties them, it has no "created" flags, so it keeps them (crates/socket-patch-core/src/vendor/pnpm_lock.rs:901-930 for package.json, and :961-985 → revert_workspace for pnpm-workspace.yaml). Removing the entries one at a time with remove <purl> in the opposite order (left-pad first, then is-number) cleans up correctly, which confirms that it depends on order.

Expected vs actual

Expected (and what 4.0.0 does): after the last vendored entry is reverted, a pnpm.overrides table, pnpm table and pnpm-workspace.yaml that vendoring created are removed, so package.json and the workspace come back byte-exact. That's what the pnpm backend's created-table tracking is for, and the single-package revert already does it.
Actual: they're kept whenever more than one entry shared them.

OS	pnpm 7.33.7 (5.4)	8.15.9 (6.0)	9.15.9	10.34.5	11.28.3	12.8.1
Linux, 2 packages	package.json residue	package.json residue (also with 3 packages)	package.json + workspace residue	package.json + workspace residue	package.json + workspace residue	package.json + workspace residue (also with 3 packages, and via `rollback`)
Linux, 1 package	byte-exact	byte-exact	byte-exact	byte-exact	untested	byte-exact
macOS / Windows	untested (probe branches blocked)

Every 2-package cell reproduced at least twice on main, and a --frozen-lockfile install after the revert passes in every cell.

Release 4.0.0 (npm @socketsecurity/socket-patch@4.0.0), same fixture with 2 packages: byte-exact on 8.15.9 and 12.8.1, with the same ledger flags and the same revert event order.

First bad commit

Bisected on pnpm 12.8.1 with the two-package fixture: 09956d90 "Cleanup: no .socket residue, locks that never outlive a command, manifest-free vendored mode (#247)" is the first bad commit. Its parent 9489b185 (#246) is good, and every commit tested between it and main is bad. The recent pnpm vendoring refactor (#583, fc356c0) didn't introduce it: b8bf049, just before it, is already bad.

[agent] Triaged: priority:p1 (pnpm). Not a duplicate, and no open or merged PR addresses it. Confirmed on main 045d7ec: the vendored pnpm backend records created_pnpm_table / created_overrides_table / created_workspace_file only on the entry that first created them (vendor/pnpm_lock.rs:402-404). The revert at :906 and :969 only removes a table or the workspace file when the entry it is reverting carries the flag, so if a flag-less entry is the one that empties the table, the residue stays. A fix should make "who created it" a property of the shared artifact, not of one ledger entry: either carry the flag forward to the surviving entries, or check "empty and created by vendoring" when the last entry is reverted.

Generated by Claude Code

[agent] Claiming this issue together with #670. The shared root cause: vendored wiring records "vendor created this shared table/file" on only the first ledger entry, so a revert removes the scaffold only when that entry happens to be reverted last. Branch: agent/fix-vendor-created-scaffold-ownership. Claim-ID: 2026-10-03T09:20:28Z-18043c

Generated by Claude Code

[agent] Draft PR: #672

Generated by Claude Code

Fix revert leaving vendored pnpm/uv scaffolding

Test pnpm two-package revert through the CLI

Update pnpm legacy-ledger golden to clean revert

Assert pnpm group-commit revert drops scaffold

[agent] New path for the same residue, from the pnpm bug-hunt routine (ledger #303), main 045d7ec, Linux. This is worth checking that PR #672 covers.

A vendored → hosted takeover with two packages (left-pad@1.3.0 + is-number@7.0.0, then scan --mode vendored, then scan --mode hosted) leaves the same "pnpm": {"overrides": {}} in package.json and the vendored pnpm-workspace.yaml scaffold. Hosted mode then appends trustLockfile: true to that leftover file:

packages:
  - '.'
overrides:
trustLockfile: true

Because the file is no longer exactly hosted mode's own scaffold, a later full rollback can't delete it either. The lock comes back byte-exact, but the 4-line workspace file and the empty pnpm.overrides stay for good, and rollback only warns pnpm_trust_lockfile_left. A frozen install after the takeover is patched, so it's still residue only.

pnpm	2 packages: vendored → hosted → rollback	1 package (control)
8.15.9 (6.0)	`package.json` residue	—
9.15.9 / 10.34.5	`package.json` + 4-line workspace residue	—
12.8.1	`package.json` + 4-line workspace residue (reproduced 2×)	clean (scaffold deleted, lock byte-exact)

Generated by Claude Code

pnpm: run 16 ledger (filed #754, #756; #636 comment)

Fix vendored revert leaving created scaffold behind (#636, #670) (#672)

Navigation Menu

Repository navigation

Vendored pnpm with two or more packages: vendor --revert and rollback leave an empty `pnpm.overrides` in package.json and (lockfile 9.0) a scaffolded pnpm-workspace.yaml behind #636

Summary

Impact

Repro (main `045d7ec`, Linux, Node 22)

Why

Expected vs actual

First bad commit

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Vendored pnpm with two or more packages: vendor --revert and rollback leave an empty pnpm.overrides in package.json and (lockfile 9.0) a scaffolded pnpm-workspace.yaml behind #636

Description

Summary

Impact

Repro (main 045d7ec, Linux, Node 22)

Why

Expected vs actual

First bad commit

Activity

mikolalysenko commented on Oct 3, 2026

mikolalysenko commented on Oct 3, 2026

mikolalysenko commented on Oct 3, 2026

mikolalysenko commented on Oct 4, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Vendored pnpm with two or more packages: vendor --revert and rollback leave an empty `pnpm.overrides` in package.json and (lockfile 9.0) a scaffolded pnpm-workspace.yaml behind #636

Repro (main `045d7ec`, Linux, Node 22)