Editing a declared patch file is neither rejected by frozen installs nor re-hashed by plain installs

[mwolson]

• aube: 1.36.0 linux-x64 (2026-07-29)
• Repro: https://github.com/mwolson/tmp-aube-issues/tree/main/pnpm-patch-edit-stale-lock-hash (./repro.sh exits non-zero while the issue reproduces; needs a real pnpm via PNPM_BIN)

Setup

One dependency with a declared patch, lockfile created by native pnpm 10.24.0 so the recorded content hash is canonically pnpm's:

# pnpm-lock.yaml (excerpt)
patchedDependencies:
  '@isaacs/string-locale-compare@1.1.0':
    hash: c73fcd10c137b7e2a95f07c5e8b12d9cefceb2ed59b266ee19933c6b7c2f35bd
    path: patches/@isaacs__string-locale-compare@1.1.0.patch

Baseline aube install on this state is fine.

Steps

Change the patch file's content in place (the repro edits one added line's text), then:

CI=1 aube install --ignore-scripts            # succeeds silently
aube install --frozen-lockfile --ignore-scripts  # succeeds silently
aube install --ignore-scripts                 # succeeds; see below

What happens

1. Both frozen forms accept the stale lockfile silently: the recorded hash is the sha256 of the previous patch content, the file on disk no longer matches, and nothing reports it.

2. The plain install applies the new patch content to the store (the installed file carries the edited line) but leaves the old hash in patchedDependencies, so the lockfile and the installation now permanently disagree. Every subsequent install keeps this split state; nothing ever repairs or reports it.

3. Native pnpm rejects the identical lockfile + patch state:

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

4. The only tool-driven way I found to refresh the hash is aube install --force, which also re-resolves unrelated floating ranges (in the real workspace this pulled in newer expo/router versions as a side effect). The practical recovery was hand-editing the recorded hash, which the next install then accepted without comment.

Expected

pnpm parity in both directions: a frozen install fails on a patch-content/hash mismatch the way pnpm does, and a plain install that applies changed patch content recomputes the hash and updates the lockfile in the same pass.

Real-world context

Hit immediately downstream of #1195: after hand-repairing the combined patch file, no install ever updated or flagged the recorded hash, so local CI=1 installs stayed green while the same tree would fail any native-pnpm frozen CI. In a repo shared between aube and pnpm users, the desync is invisible to the aube side and breaking for the pnpm side.

Related: #1195 / #1196 (patch-commit layering), #1029 (re-resolve dropped pnpm patch metadata).

[jdx]

Yes — this is part of #1196 now because recommitting an existing patch necessarily edits its declared file in place and would otherwise leave pnpm's recorded patch identity stale.

Commit e9f47b8 adds patch-hash drift to lockfile freshness checks:

• frozen installs (including CI's auto-frozen mode) fail with ERR_AUBE_LOCKFILE_CONFIG_MISMATCH when the current patch content differs from pnpm-lock.yaml
• plain installs reuse the existing locked graph, recompute the patch hash, update all (patch_hash=...) identities, and apply the edited patch
• the regression test covers both directions

PR: #1196

AI-assisted — Tool: Codex; model: openai/gpt-5; version: unavailable.

[mwolson]

Retested the minimal repro with aube 1.37.0. pnpm-patch-edit-stale-lock-hash/repro.sh now passes: CI and explicit frozen installs reject edited patch content with ERR_AUBE_LOCKFILE_CONFIG_MISMATCH, while a plain install applies the edit and refreshes the lockfile hash. Native pnpm accepts the resulting lockfile. The fix shipped in PR #1196 preserve existing patches and refresh hashes. The repro index is updated at https://github.com/mwolson/tmp-aube-issues/tree/main/pnpm-patch-edit-stale-lock-hash.