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

Ouverte
  • Quelque chose ne va pas ?
#2,153 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@robhogan y travaille déjà.

Depuis le 4/11/2026.

  • #2174 par @robhogan — ouverte

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
22/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
javascript, react-native
Domaine
build-system

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
JavaScript
Étoiles
5.7k
Forks
715
Merge moyen
3 j 14 h
PR mergées (30 j)
77

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de react/metro

Toutes les issues de react/metro

Issues similaires

Plus d'issues JavaScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.