Resolver: Read `exports` from the package root, not the closest `package.json`

Aperta
  • Qualcosa non va?
#2,153 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@robhogan ci sta già lavorando.

Dal 4/11/2026.

  • #2174 di @robhogan — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
22/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
javascript, react-native
Ambito
build-system

Direzione di ricerca

Start in packages/metro-resolver/src/resolve.js around the line where the package is looked up once (about L420), and trace how resolveFromNodeModulesPath, extraNodeModules and Haste pass the package root down. The change adds an opt-in resolver.unstable_resolveExportsFromPackageRoot flag that reads "exports" via getPackageForModule(packageRoot) when the subpath is empty. Done means the flag gates the new behaviour, existing tests pass with it off, and new tests cover nested package.json with root exports.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Metro reads "exports" from the package.json closest to the requested subpath, not the one at the package root. So a nested {"type": "commonjs"} or a legacy shim package.json hides the root's "exports", which is different to Node's PACKAGE_RESOLVE, webpack and Vite. Previously reported in #1517 and #1582, this is to track the fix.

Examples I've seen in real apps (AI-driven comparison): @floating-ui/utils/dom on Bluesky web gets the legacy shim's build instead of dist/floating-ui.utils.dom.mjs, and on Mattermost, ESM imports of rxjs/operators get dist/cjs while rxjs gets dist/esm5. @kitten and @Nezz have seen the same thing break swr.

The fix should be small now that #2134 looks the package up once, here:

https://github.com/react/metro/blob/9e61545565438f265ffbced0322a97aea9908888/packages/metro-resolver/src/resolve.js#L420

Metro converts specifiers to absolute candidate paths early, so the caller has to pass the package root down. resolveFromNodeModulesPath has parsedSpecifier.packageName, extraNodeModules has the mapped directory and Haste has the directory of its package.json.

  • For "exports", use getPackageForModule(packageRoot). It gives a real rootPath, so pnpm symlinks work, and packageRelativePath comes from the specifier's subpath.
  • If packageRelativePath isn't empty, there's no package.json at the root, so keep using the closest to the target.
  • "browser" redirections, "imports" and self-references all keep using the closest package.json, which is correct for those.

This should go behind resolver.unstable_resolveExportsFromPackageRoot, off by default, so that we can get it out in 0.87.x without changing what anyone resolves, and then enable it by default for 0.88.

It's breaking because some packages only work on native through a nested "browser" field that this bypasses. As @Om-singhaI found, @mswjs/interceptors/fetch goes from its browser build to its Node build, which needs node:zlib. nanoid/async (nanoid 3) also moves, and needs unstable_applyBrowserSpecAfterExports on as well to avoid importing crypto. Subpaths with a nested package.json that aren't in the root's "exports" will now warn, then fall back as they do today.

Lingua principale
JavaScript
Stelle
5.7k
Fork
715
Merge medio
3g 14h
PR unite (30g)
77

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di react/metro

Tutte le issue di react/metro

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.