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

Offen
  • Stimmt etwas nicht?
#2,153 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@robhogan arbeitet bereits daran.

Seit 04.11.2026.

  • #2174 von @robhogan — offen

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
22/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
javascript, react-native
Bereich
build-system

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
JavaScript
Sterne
5.7k
Forks
711
Ø Merge
3 T. 14 Std.
Gemergte PRs (30 T.)
77

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus react/metro

Alle Issues in react/metro

Ähnliche Issues

Weitere Issues zu JavaScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.