Hoisted workspace materializes the same React version twice when an earlier importer pins another version

[mwolson]

• Repo: jdx/aube
• Category: Troubleshooting and Bugs
• Observed: aube 1.40.0 linux-x64 (2026-08-13)
• Compared with: native pnpm 11.21.0 and 10.24.0, Node v24.19.0, Linux x86_64
• Related but distinct: Hoisted monorepo: identical deps become separate realpaths per workspace package #1242 hoisted-shared-realpath / fix(linker): share hoisted deps across workspace importers #1243 share hoisted deps (same version across importers now shares a root placement). Hoisted workspace auto-install reinstalls on every command (`installed entry missing`) #1292 hoisted-auto-install-freshness is a different freshness-check issue and is not this report.
• Case: https://github.com/mwolson/tmp-aube-issues/tree/main/hoisted-react-peer-duplication

Summary

In a two-importer workspace under node-linker=hoisted, aube lets the alphabetically earlier importer claim the workspace-root react slot. A later importer that pins a different React version, plus a hoisted peer-dependent package resolved in that later importer's peer context, then get two distinct react@<later> package-root realpaths. Node loads two module identities of the same version. Native pnpm hoisted places the later version once at the workspace root and nests only the earlier pin.

This is not explained by incompatible peer ranges. zustand@5.0.11 declares react: ">=18.0.0" (optional). Both 19.2.3 and 19.2.6 satisfy that range.

Minimal graph

Public packages only:

• packages/mobile depends on react@19.2.3
• packages/web depends on react@19.2.6 and zustand@5.0.11
• workspace root has no React of its own

packages/mobile is earlier than packages/web in path order, which is what triggers aube's current root winner. Renaming the 19.2.3 importer to packages/zzz makes aube match pnpm.

Repro

https://github.com/mwolson/tmp-aube-issues/tree/main/hoisted-react-peer-duplication

git clone https://github.com/mwolson/tmp-aube-issues.git
cd tmp-aube-issues/hoisted-react-peer-duplication
./repro.sh

The script exits 0 when web and zustand resolve to the same react package-root realpath, and 1 when they do not. Isolated is the setup control and passes. Hoisted fails on aube 1.40.0.

Direct commands:

aube install --node-linker=isolated --ignore-scripts
# web and zustand both resolve to node_modules/.aube/react@19.2.6/...  (same realpath)

aube install --node-linker=hoisted --ignore-scripts
# web    -> packages/web/node_modules/react                 (19.2.6)
# zustand -> node_modules/zustand/node_modules/react        (19.2.6)
# mobile -> node_modules/react                              (19.2.3)

Aube 1.40.0 hoisted placements

From node_modules/.aube-state/hoisted-placements.json:

{
  "react@19.2.3": ["node_modules/react"],
  "react@19.2.6": [
    "packages/web/node_modules/react",
    "node_modules/zustand/node_modules/react"
  ],
  "zustand@5.0.11(react@19.2.6)": ["node_modules/zustand"]
}

require("react") from packages/web and from node_modules/zustand returns different module exports. Isolated aube on the same manifests returns the same export.

Native pnpm hoisted (nodeLinker: hoisted)

pnpm 11.21.0 node_modules/.modules.yaml:

{
  "nodeLinker": "hoisted",
  "hoistedLocations": {
    "react@19.2.6": ["node_modules/react"],
    "react@19.2.3": ["packages/mobile/node_modules/react"],
    "zustand@5.0.11(react@19.2.6)": ["node_modules/zustand"]
  }
}

pnpm 10.24.0 records the same locations. Web and zustand both resolve to the single root react@19.2.6 and share one module export.

Why this is not just "two React versions in one workspace"

Two exact React pins are an intentional workspace fact. Isolated aube already isolates them correctly: one react@19.2.6 identity for web plus zustand, and react@19.2.3 for mobile.

The hoisted failure is the extra split of react@19.2.6 into two package roots after 19.2.3 occupies the workspace root. #1243 share hoisted deps already says compatible dependencies should share one physical package at the root when they can, and that version or peer-context conflicts remain nested. Nesting 19.2.3 vs 19.2.6 is expected. Materializing 19.2.6 twice is the part that differs from pnpm and that produces two React identities in one web runtime.

Questions

1. When a version cannot occupy the workspace root, should every placement of that same version still share one package-root realpath?
2. Should the root winner prefer the version needed by more dependents or peer contexts, as pnpm does here, instead of the first importer in workspace order?
3. Is this in scope as a follow-up to fix(linker): share hoisted deps across workspace importers #1243 share hoisted deps, or is first-importer-wins plus multiple nest directories considered supported hoisted semantics?

[jdx]

Confirmed — this is a bug in the workspace hoist winner selection. The linker let the first importer in path order claim the root name slot, while pnpm/Yarn prefer an explicit root dependency and otherwise rank versions by distinct dependents plus peer dependents.

PR #1296 adds that preference pass and regression coverage: #1296

I also verified the public reproduction directly: react@19.2.6 now lands once at the workspace root, mobile keeps 19.2.3 locally, and web/zustand share both the React realpath and module export.

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