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

Abierto
  • ¿Algo no está bien?
#2,153 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@robhogan ya está trabajando en esto.

Desde el 4/11/2026.

  • #2174 de @robhogan — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
22/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
javascript, react-native
Área
build-system

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
JavaScript
Estrellas
5.7k
Forks
711
Merge medio
3 d 14 h
PR fusionados (30 d)
77

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de react/metro

Todos los issues de react/metro

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.