Non-frozen re-resolve rewrites the pnpm lockfile without pnpm-compatible patch metadata for a still-declared patch

[mwolson]

• aube version: 1.26.0 (also tested a debug build of master at 730bc4ce,
  which includes fix(install): ignore stale pnpm patch entries #1022)
• pnpm version compared: 11.11.0
• Repro repo: https://github.com/mwolson/tmp-aube-issues
• Case: pnpm-patch-reresolve-drop

Summary

When a non-frozen aube install re-resolves because of unrelated manifest
drift, the rewritten pnpm-lock.yaml loses the pnpm-compatible patch
metadata for a patch the workspace still declares and the old lockfile still
recorded correctly. pnpm 11.11.0 re-resolves the identical starting state
keeping both the applied patch and the full metadata.

This is related to #1019 but distinct: there the lockfile records a patch the
workspace no longer declares and aube fails hard. Here the workspace
declaration and lockfile agree with each other, the drift is unrelated (a new
plain dependency), and the metadata loss is silent.

On 1.26.0 the rewritten lockfile keeps only an empty patchedDependencies:
key and no (patch_hash=...) suffixes. On master, #1022 restores the
top-level entry, but writes it in path form
(is-odd@3.0.1: patches/is-odd@3.0.1.patch) instead of the pnpm 11 hash
form, and the importer version and snapshot key still lose their
(patch_hash=...) suffixes. A subsequent native pnpm --frozen-lockfile
install on master's rewritten lockfile then fails:

ERR_PNPM_LOCKFILE_CONFIG_MISMATCH  Cannot proceed with the frozen
installation. The current "patchedDependencies" configuration doesn't match
the value found in the lockfile

So in a repo shared between aube and native pnpm users (or with CI running
frozen installs), one aube non-frozen install breaks everyone else's frozen
installs even though the patch never changed.

How the state arises

This is the normal "merge updates manifests but keeps the old lock" flow:

1. package.json pins is-odd@3.0.1, patched via pnpm-workspace.yaml
patchedDependencies, lockfile generated by pnpm 11.11.0 and committed
   (hash-form top-level entry, (patch_hash=...) suffixes on the importer
   version and snapshot key).
2. A later change adds is-positive@3.1.0 to package.json without
   rerunning install. The patch declaration and its lockfile entry are
   untouched and still consistent with each other.

We hit this on a real Expo monorepo where a rebase brought in unrelated
dependency bumps while patchedDependencies stayed the same.

Steps to reproduce

git clone https://github.com/mwolson/tmp-aube-issues
cd tmp-aube-issues/pnpm-patch-reresolve-drop
./repro.sh

The script runs native pnpm first (expected to succeed, exit 2 if the
environment is broken), then aube on a fresh copy of the same state and
checks three things: the patched content is linked, the rewritten lockfile
keeps hash-form patch metadata, and a native pnpm frozen install accepts the
rewritten lockfile. Exit 0 means aube behaved correctly; exit 1 means the
issue was observed. PNPM_BIN selects the native pnpm binary and AUBE_BIN
selects the aube binary, so the same script verified both 1.26.0 and the
master build.

Store labeling side effect

Both aube versions link the patched package from a store directory without a
patch label (node_modules/.aube/is-odd@3.0.1/... rather than an
is-odd@3.0.1_patch_hash=... name). In the small repro the content in that
directory happens to be patched. In the larger monorepo, a plain-named store
entry already existed with unpatched content, and the re-resolve silently
linked the unpatched files: the app built and ran with the patch missing and
nothing failed. That silent variant is what makes this worth fixing beyond
the lockfile shape.

Expected behavior

A non-frozen re-resolve keeps the still-declared patch applied, writes the
pnpm 11 hash-form patchedDependencies entry and (patch_hash=...)
suffixes, and produces a lockfile that native pnpm accepts in frozen mode,
matching what pnpm 11.11.0 does from the same state.

[jdx]

Thanks for the detailed report and repro. Confirmed: #1022 kept the declared patch applied during a fresh re-resolution, but the pnpm writer still replaced pnpm 11 hash metadata with the manifest path and omitted the (patch_hash=...) identities from importer and snapshot references.

The fix is ready for review in #1035. It now preserves existing pnpm patch hashes or derives pnpm-compatible SHA-256 hashes from current patch files (including CRLF normalization), then emits the hash consistently on direct, transitive, snapshot, and peer-context references.

Validation includes the full Rust test suite, clippy, the focused patch BATS suite, and the supplied pnpm-patch-reresolve-drop repro. The final native pnpm 11 frozen install now succeeds.

This comment was generated by Codex.

[mwolson]

Retested with aube 1.31.0 (linux-x64, 2026-07-21) against the minimal repro in https://github.com/mwolson/tmp-aube-issues (pnpm-patch-reresolve-drop).

repro.sh now exits 0: after a non-frozen re-resolve for unrelated manifest drift, the rewritten pnpm-lock.yaml keeps pnpm-compatible patch metadata and a subsequent native pnpm 11.15.1 --frozen-lockfile install succeeds.

Fix shipped in aube 1.28.0 via #1035 (with groundwork from #1022). Marking the maintainer reply as the answer.

[mwolson]

Retested with aube 2.6.1 linux-x64 (2026-09-29): the 1.28.0 fix keeps the
patched package's own lockfile identity, but peer references to a patched
package still lose the patch hash on a non-frozen re-resolve.

Minimal repro: https://github.com/mwolson/tmp-aube-issues/tree/main/pnpm-patch-peer-suffix-drop

react@19.1.0 is patched, and react-dom@19.1.0 peers on it. The committed
pnpm-lock.yaml was written by pnpm 11.10.0 before an unrelated dependency
(is-positive) was added to package.json. After pnpm install --no-frozen-lockfile the peer-suffixed snapshot key is:

react-dom@19.1.0(react@19.1.0(patch_hash=4d0f60e0...)):

After aube install --no-frozen-lockfile from the same state it is:

react-dom@19.1.0(react@19.1.0):

The installed react is still the patched copy, and pnpm accepts the
rewritten lockfile, but react@19.1.0 names no snapshot (the lockfile only has
react@19.1.0(patch_hash=...)), and pnpm never restores the hash. In a real
pnpm workspace (pingdotgg/t3code, which patches effect), one aube install
rewrote about 1,600 lockfile lines, including 93 (effect@...(patch_hash=...))
peer suffixes.

./repro.sh (with PNPM_BIN pointing at a real pnpm) checks the pnpm control
and exits 1 on the aube rewrite.

[jdx]

Confirmed the patched-peer follow-up. The writer was removing patch hashes from nested peer references, then restoring only the package's own hash.

The fix is ready for review in #1685. It preserves patched peer identities in importer versions, snapshot keys, and dependency references, including nested contexts, npm aliases, and optional dependencies.

Your pnpm-patch-peer-suffix-drop/repro.sh now exits 0 against native pnpm 11.27.1. The full Rust suite, all 15 patch integration tests, formatting, shell lint, and workspace clippy on stable Rust also pass. I’m following the PR checks and review feedback.

AI-assisted — Tool: Codex; model: unavailable; version: unavailable.

[mwolson]

Retested with the release, aube 2.7.0 linux-x64 (2026-10-07):

PNPM_BIN=/path/to/real/pnpm ./repro.sh

pnpm-patch-peer-suffix-drop/repro.sh now exits 0 with native pnpm 12.8.1 as the control. After the non-frozen re-resolve, aube keeps react-dom@19.1.0(react@19.1.0(patch_hash=...)).

In pingdotgg/t3code, a non-frozen aube install now keeps the patch hash on every effect@4.0.1 peer suffix, with no bare (effect@4.0.1) references left.

Fix shipped in aube 2.7.0 via #1685. Thanks for the quick turnaround.