Settled file: directory deps keep a stale store copy when the source tree changes (warm-path "Already up to date")

[mwolson]

• aube version: 1.26.0 (store-key and warm-path logic also inspected on
  master at 730bc4ce; no fix for this path in the recent history)
• pnpm version compared: 11.11.0
• Repro repo: https://github.com/mwolson/tmp-aube-issues
• Case: pnpm-file-dep-stale-store

Summary

After a workspace install has settled, aube keys and freezes
file:<dir> packages under
node_modules/.aube/<name>@file+<16-hex>/ and the warm path short-circuits
with "Already up to date" when only the linked source directory changes.
Native pnpm 11.11.0, from the same settled state, re-adds the package and
refreshes the installed copy so consumers see the new files.

This is distinct from #1018 (plain unified patch headers) and #1029
(patch metadata dropped on non-frozen re-resolve). Those are patch
pipeline bugs; this is about local file: directory content not
invalidating either the store key or the warm-path freshness check.

How the state arises

1. A workspace package depends on a nested local package via
   "@scope/pkg": "file:./modules/pkg" (same shape as
   apps/mobile -> file:./modules/t3-markdown-text in a real Expo
   monorepo).
2. aube install materializes a store copy. The directory name looks
   like @scope+pkg@file+c528c7e402d4100e where the hex suffix is a
   path hash, not a content hash.
3. Later the source tree under modules/pkg changes (new export, new
   type field, etc.) without editing any workspace package.json or
   the lockfile.
4. CI=1 aube install reports "Already up to date" and leaves the
   stale store files in place. Typecheck / runtime then fail against
   the old copy even though the source on disk is correct.

We hit this on aube 1.26.0 with a real monorepo: after adding a
fillWidth prop to a local module's types, install still served a
store copy without that prop until the .aube/*@file+* entry was
removed by hand.

Store key (from aube source)

LocalSource::dep_path in crates/aube-lockfile/src/source.rs
hashes only the POSIX path of the file: target (first 16 hex chars of
SHA-256), not the directory contents:

// comment in source.rs:
// "we hash the raw path bytes and suffix the first 16 hex chars"
// ...
_ => hasher.update(self.path_posix().as_bytes()),
// ...
format!("{name}@{}+{short}", self.kind_str())

So the key is stable for a given path forever. Changing files under that
path never produces a new store entry name.

Separately, check_needs_install in crates/aube/src/state.rs decides
the warm path from lockfile hash, workspace package.json hashes, layout
name/version of already-materialized packages, and settings. It does not
re-hash the contents of file: source directories, so a content-only
edit is invisible and install exits with "Already up to date".

Steps to reproduce

git clone https://github.com/mwolson/tmp-aube-issues
cd tmp-aube-issues/pnpm-file-dep-stale-store
PNPM_BIN=/path/to/real/pnpm-11.11.0 ./repro.sh

The script:

1. Installs with native pnpm, mutates the nested file: source
   (marker: "v1" -> "v2"), reinstalls, and expects marker v2.
2. Repeats with aube after settling the warm path (three installs so
   the third is "Already up to date"), mutates the same way, reinstalls,
   and checks the installed marker.
3. If aube is stale, wipes node_modules/.aube/*@repro+local-mod@file+*
   and reinstalls to show the workaround restores v2.

Exit 0 means aube refreshed; exit 1 means the issue was observed.
PNPM_BIN must point at real pnpm (not the aubeshim shim). AUBE_BIN
selects the aube binary.

Observed matrix on this machine:

Manager	After source mutate + install	Result
pnpm 11.11.0	re-adds package, marker=v2	fresh
aube 1.26.0	"Already up to date", marker=v1	stale
aube after wipe of @file+* store dir	reinstall, marker=v2	workaround

Expected behavior

A plain aube install after a content change under a file: directory
dependency should either re-import that directory into the store (like
pnpm 11 does) or otherwise invalidate the warm path so consumers see the
new files without a manual store wipe.

Workaround

rm -rf node_modules/.aube/@scope+pkg@file+*
# or more broadly:
# rm -rf node_modules/.aube/*@file+*
aube install

[jdx]

Thanks for the detailed report and repro — the diagnosis was correct. The fix is in #1034.

The dependency identity stays path-based, but aube now records a deterministic content fingerprint for copied file: directories (and portals), checks it before taking the warm "Already up to date" path, and replaces the existing path-keyed .aube materialization during the resulting full install. The regression test uses the same equal-size v1 → v2 mutation and verifies the installed copy refreshes.

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-file-dep-stale-store).

repro.sh now exits 0: after a settled install, mutating the nested file: source tree and running CI=1 aube install refreshes the installed content (marker v1 → v2), matching native pnpm 11.15.1.

Fix shipped in aube 1.28.0 via #1034. Marking the maintainer reply as the answer.