Non-frozen aube install fails reading a stale lockfile patch path that re-resolution never uses

[mwolson]

• aube version: 1.26.0 (also reproduced on 1.25.2)
• pnpm versions compared: 10.24.0 and 11.11.0
• Repro repo: https://github.com/mwolson/tmp-aube-issues
• Case: pnpm-patch-stale-lock-path

Summary

When a committed pnpm-lock.yaml still records a patchedDependencies entry
for a patch key the workspace no longer declares, and that patch file has been
deleted, a plain non-frozen aube install fails hard:

× failed to read patch file <repo>/patches/is-odd@3.0.0.patch for is-odd@3.0.0:
│ No such file or directory (os error 2)

pnpm 10.24.0 and 11.11.0 both re-resolve to the new version, apply the new
patch, and rewrite the lockfile from the identical starting state.

How the state arises

This is the normal "upgrade a patched dependency" flow with a stale lock, e.g.
after a merge or rebase that updates manifests but keeps the old lockfile:

1. package.json pins is-odd@3.0.0, patched via pnpm patch is-odd@3.0.0 +
   pnpm patch-commit --patches-dir patches (pnpm 10.24.0), lockfile committed.

2. A later change upgrades to is-odd@3.0.1: manifest bumped, patch
   regenerated as patches/is-odd@3.0.1.patch, workspace
   patchedDependencies key moved to is-odd@3.0.1, old
   patches/is-odd@3.0.0.patch deleted.

3. pnpm-lock.yaml is not regenerated, so it still contains:

   patchedDependencies:
     is-odd@3.0.0:
       hash: 3d1a5c64631de20da5952e4fedb221fe42e03af624354d0309548ce71f3302d5
       path: patches/is-odd@3.0.0.patch

We hit this on a real Expo monorepo where a rebase brought in an upgraded
@expo/metro-config patch while the lockfile still referenced the deleted
previous patch file.

Steps to reproduce

git clone https://github.com/mwolson/tmp-aube-issues
cd tmp-aube-issues/pnpm-patch-stale-lock-path
./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. Exit 0
means aube behaved correctly; exit 1 means the failure above was observed.
Both legs pass --no-frozen-lockfile so the comparison stays non-frozen even
when CI is set.

Expected behavior

A non-frozen install re-resolves against the manifest and workspace
patchedDependencies, drops the stale lockfile entry, and never needs the
deleted file, matching pnpm. A frozen install failing here would be
reasonable; a non-frozen one failing seems like an eager read of lockfile
patch state that resolution is about to discard.

Additional observations

• If the old patch file still exists on disk (even though nothing references
  it after re-resolution), aube install succeeds and correctly resolves to
  is-odd@3.0.1 with the new patch applied. So the failing read is of a file
  the new resolution never uses.

• With a pnpm 11 lockfile in the same drifted state (pnpm 11 writes hash-only
  patchedDependencies entries), aube fails the same way but treats the hash
  string itself as the patch file path:

  × failed to read patch file <repo>/02efb892c0aa62e77ab535074021159d4eb5764f187cecb6b759227dcc9ebfec
  │ for is-odd@3.0.0: No such file or directory (os error 2)
  

• A fresh pnpm 11 lockfile with no drift installs fine under aube, so the
  hash-only format itself is handled when the workspace key matches.

[jdx]

Thanks for the detailed report and repro. Confirmed: after a non-frozen re-resolution, aube was restoring the prior lockfile patchedDependencies metadata, then eagerly reading both that stale entry and the current workspace declaration. The pnpm 11 scalar form was also being interpreted as a path on this stale-entry route.

The fix is ready for review in #1022. Fresh pnpm re-resolutions now replace the overlaid patch map with the current package.json / pnpm-workspace.yaml declarations before materialization and lockfile writing. Frozen lockfile reuse remains unchanged.

The PR includes end-to-end regression coverage for both the pnpm 10 object form and pnpm 11 hash-only form from the report. The focused tests and completed CI checks are passing.

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-stale-lock-path).

repro.sh now exits 0: non-frozen re-resolve moves past the stale lockfile patch path and applies the current workspace patch, matching native pnpm 11.15.1.

Fix shipped in aube 1.27.0 via #1022. Marking the maintainer reply as the answer.