Isolated GVS keeps a stale nested identity for a patched dependency

[mwolson]

• Repro repo: https://github.com/mwolson/tmp-aube-issues
• Repro case: isolated-patched-gvs-stale-identity
• aube version: 1.40.0 linux-x64 (2026-08-13)
• Node version: v24.19.0
• pnpm comparison: 11.21.0 isolated

Summary

Isolated aube with the default-on global virtual store can leave a third-party package's sibling node_modules/<dep> pointing at a different store identity than the project importer. A warm aube install does not rewrite that nested GVS link. --disable-global-virtual-store does.

I first hit this with a workspace-level patchedDependencies entry for effect@4.0.0-beta.103. The project resolved effect@4.0.0-beta.103-<hash> while @effect/platform-node's GVS instance still linked effect@4.0.0-beta.103_patch_hash=.... The bytes were the same. The realpaths were not. Rolldown inlined both copies, Effect's pre-response WeakMap split, and packaged desktop GET/POST responses lost Access-Control-Allow-Origin.

Expected

After aube install --node-linker=isolated, every importer of a patched is-number@7.0.0 resolves one package-root realpath. A later warm install should repair a stale nested GVS sibling link.

Actual

A fresh install is unified. If only the isolated sibling link under to-regex-range's GVS instance is pointed at a second store identity, a warm install leaves the split in place.

from app            .../is-number@7.0.0-<hash>/node_modules/is-number
from to-regex-range .../is-number@7.0.0-<hash>-stale-identity/node_modules/is-number
same realpath       false

--disable-global-virtual-store repairs the same retarget. Native pnpm 11.21.0 isolated keeps one is-number@7.0.0_patch_hash=... identity for both importers.

Repro

git clone https://github.com/mwolson/tmp-aube-issues
cd tmp-aube-issues/isolated-patched-gvs-stale-identity
./repro.sh

repro.sh exits non-zero when the issue is present. It uses a private AUBE_GLOBAL_VIRTUAL_STORE_DIR so it does not touch the user GVS.

Related

• Hoisted monorepo: identical deps become separate realpaths per workspace package #1242 (hoisted same-version realpaths; fixed in 1.38.1)
• Hoisted workspace materializes the same React version twice when an earlier importer pins another version #1293 (hoisted React peer nesting)
• Metro cannot resolve packages whose realpath is in the global virtual store #1294 (Metro cannot resolve GVS realpaths)

[jdx]

Thanks for the detailed reproducer. I confirmed this on 1.40.0 and opened #1299.

There were two cache-hit layers involved: the normal warm path returned before linking because install state did not track nested GVS links, and a forced/full install treated an existing parent GVS entry as complete without reconciling its dependency links. That is why even --force did not repair the split identity.

The PR records the expected nested-link topology in install state, invalidates the warm path when it drifts, and reconciles stale nested links in cached GVS entries. The supplied isolated-patched-gvs-stale-identity/repro.sh now completes with one realpath after the warm install. The full Rust test suite, clippy, and formatting checks also pass.

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

[mwolson]

Confirmed fixed with aube 1.41.0 using isolated-patched-gvs-stale-identity. A warm install now repairs the deliberately retargeted nested GVS link, leaving the project importer and to-regex-range on the same is-number realpath. The fix shipped in #1299 repair-stale-gvs-links. Thanks!