Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Async chunk URLs drop the file extension, so .cjs async imports fail with "Requiring unknown module"

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

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
74/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
javascript, react-native
Área
build-system

Línea de trabajo

Read Serializers/helpers/js.js, focusing on getModuleParams and the chunk URL construction, then trace parseBundleOptionsFromBundleRequestUrl to understand how extensions are handled. Reproduce the lazy import with a package resolving to dist/index.cjs and verify the served chunk registers the same module id as the importing bundle; also confirm the existing .ts async boundary remains valid.

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

Descripción

Do you want to request a feature or report a bug?

Bug.

What is the current behavior?

With lazy bundling, an import() of a package that resolves to dist/index.cjs throws at runtime: Requiring unknown module "11122".

getModuleParams builds the chunk URL from the resolved path but strips its extension (Serializers/helpers/js.js):

const bundlePath = path.relative(options.serverRoot, dependency.absolutePath);
paths[id] = '/' + path.join(
    path.dirname(bundlePath),
    path.basename(bundlePath, path.extname(bundlePath)),  // `.cjs` is lost here
) + '.bundle?' + searchParams.toString();

The dependency resolved to dist/index.cjs is addressed as /…/dist/index.bundle, and when the server resolves that entry it picks dist/index.js via sourceExts — a different file, a different module id. The served chunk never defines the id baked into the importing bundle.

Measured on an Android dev bundle (Metro 0.84.4, Expo SDK 57) for @walletconnect/core (just one example — any package with this exports shape is affected), whose exports map is { ".": { "module": "./dist/index.js", "default": "./dist/index.cjs" } }:

module id file
main bundle expects 11122 dist/index.cjs
served chunk defines 11125 dist/index.js

If the current behavior is a bug, please provide the steps to reproduce and a minimal repository on GitHub that we can yarn install and yarn test.

  1. npx create-expo-app with expo-dev-client
  2. yarn add @walletconnect/core
  3. await import('@walletconnect/core') on a path that runs at startup
  4. start the dev server and open the app

Any package shipping dual builds with different extensions and no require/import conditions hits this. .mjs should be affected the same way.

What is the expected behavior?

The chunk URL addresses the file that was actually resolved, so the chunk registers the same module id as the importing bundle.

Possible fix

Keep the extension. parseBundleOptionsFromBundleRequestUrl already strips exactly one trailing extension (.replace(/\.[^/.]+$/, '')), so both index.cjs.bundle → index.cjs and today's exports.ts.bundle → exports.ts resolve exactly, and no server-side change is needed:

paths[id] = '/' + bundlePath.split(path.sep).join('/') + '.bundle?' + searchParams.toString();

I patched exactly this in @expo/metro-config's fork of the file (serializer/fork/js.ts, identical code, carrying a // TODO: This is not the proper Metro URL encoding of a file path) and re-measured the same app: the @walletconnect/core chunk now registers 11122 → dist/index.cjs, and an existing .ts async boundary in the same bundle still matched (id 11117). The split also fixes the backslashes path.join would produce on Windows. Not tested with web splitChunks, worker async type, or on Windows.

Please provide your exact Metro configuration and mention your Metro, node, yarn/npm version and operating system.

Metro 0.84.4, Expo SDK 57 (expo 57.0.8), React Native 0.86, Node 24, Yarn 4.18, macOS. Default Expo Metro config plus a custom resolveRequest that does not touch these packages.

Lenguaje dominante
JavaScript
Estrellas
5.6k
Forks
696
Merge medio
15 h 5 min
PR fusionados (30 d)
10

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.