Skip to content

Commit d243919

Browse files
committed
Fix migration wipe of revert wiring in pnpm vendor
When package.json and pnpm-lock.yaml are already in sync (from a previous vendor operation) but pnpm-workspace.yaml needs creation for pnpm 11 migration, the code was creating a new VendorEntry with only the workspace wiring record. This replaced the existing ledger entry, losing the package.json and lock revert wiring. The fix returns AlreadyPatched when the core surfaces (package.json and pnpm-lock.yaml) are in sync, regardless of whether the workspace file needs updating. This preserves the existing ledger entry with its full wiring records, maintaining revert capability.
1 parent a23abb1 commit d243919

1 file changed

Lines changed: 8 additions & 5 deletions

File tree

crates/socket-patch-core/src/vendor/pnpm_lock.rs

Lines changed: 8 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -271,11 +271,14 @@ pub async fn vendor_pnpm(
271271
Err(e) => return done_failure(purl, format!("{PNPM_WORKSPACE} surgery failed: {e}")),
272272
};
273273

274-
if !pkg_changed && !lock_changed && ws_edit.new_text.is_none() {
275-
// Everything already carries this uuid + the packed integrity: the
276-
// project is in sync. The tarball re-pack above was byte-identical
277-
// by determinism; synthesize AlreadyPatched and record nothing (the
278-
// existing ledger entry stays authoritative).
274+
if !pkg_changed && !lock_changed {
275+
// package.json and the lock already carry this uuid + the packed
276+
// integrity: the core wiring is in sync. The tarball re-pack above was
277+
// byte-identical by determinism. Even if the workspace file (pnpm >= 11
278+
// surface) needs first-time creation during migration, that must not
279+
// replace the ledger entry and wipe package.json/lock revert wiring.
280+
// Synthesize AlreadyPatched and record nothing (the existing ledger
281+
// entry stays authoritative).
279282
return done(
280283
already_patched_result(purl, &project_root.join(&rel_tgz), &record.files),
281284
None,

0 commit comments

Comments
 (0)