Feature: let a config hold a hot-reload update until a build the change started has written its output

Abierto
  • ¿Algo no está bien?
#2,133 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
javascript, react-native
Área
backend, devtools

Línea de trabajo

Read the cited HmrServer.js update flow and IncrementalBundler.js graph-update logic, along with the reproduction repository's metro.config.js and test.js. Start by tracing how updates are computed for both hot reload and repeated bundle requests; determine how an awaited config hook could include files written by the build. Done means a supported option produces one update containing both screen.js and generated.js in the reproduction.

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?

A feature.

What is the current behavior?

A tool that derives a module from other files (a CSS compiler, a code generator) hears a change, runs its build and writes its output, a module the app imports. Metro computes the hot-reload update for the change that started the build on its own schedule: HmrServer debounces the delta bundler's change events by 50 ms and then calls IncrementalBundler.updateGraph (HmrServer.js#L193-L206, #L363), which takes only the changes the file map has reported by then (IncrementalBundler.js#L292-L303). Unless the build finishes inside the debounce, its output reaches the file map as a later change and goes out in a second update, so for one update the app runs the changed module against the old generated one: a class name with no styles yet, a call into a generated module that does not have the new export.

Nothing public lets a config make an update wait for that build. A file map plugin's onChanged returns void (flow-types.js#L309), serializer.experimentalSerializerHook runs after the delta is computed and is not awaited (IncrementalBundler.js#L305), and server.unstable_onServerCreated hands over the server with no hook on its updates. The only way I found is replacing updateGraph on the server's IncrementalBundler with a method that first waits for the build and for the file map to report what it wrote.

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.

It is not a bug, but this repository shows the two updates: https://github.com/YevheniiKotyrlo/metro-hold-update-for-generated-module

index.js requires screen.js, which names a class, and generated.js, which holds the styles for it. build.js stands in for the tool: whenever screen.js changes, it writes generated.js from it, taking 300 ms. test.js starts Metro with metro.config.js, requests the bundle, registers it on /hot, changes the class in screen.js, and prints each update until one carries generated.js.

yarn install
yarn test
yarn test:held

yarn test:

Metro 0.87.2, no hold
bundle: HTTP 200
edited screen.js: className card -> banner
update 1: screen.js
update 2: generated.js
FAIL: the update carrying screen.js does not carry generated.js

yarn test:held, where metro.config.js replaces updateGraph as described above:

Metro 0.87.2, updates held
bundle: HTTP 200
edited screen.js: className card -> banner
update 1: screen.js, generated.js
PASS: screen.js and generated.js arrived in one update

That is the reproduction at fb66b7330c on Metro 0.87.2. main at a87d864565, built into the reproduction's node_modules with PACKAGES_DIR=<reproduction>/node_modules node scripts/build.js, prints the same in three runs of each.

What is the expected behavior?

A supported way for a config to make Metro's next update wait for work a change started, for every update Metro computes (HmrServer's and a repeated bundle request's). For example, an async server option Metro awaits before it computes a delta, resolving to the files the work wrote, which Metro then takes into that delta:

// metro.config.js
module.exports = {
  server: {
    // The name and shape are only a sketch.
    unstable_beforeUpdate: async () => {
      await builds.settled();
      return [generatedPath];
    },
  },
};

With it, the reproduction's yarn test would print one update carrying screen.js and generated.js, as yarn test:held does today.

#1902 (cross-file transform inputs) and #2036 (virtual modules from the resolver) are related: virtual modules would let generated source skip the file system, but neither orders an update after the build that produces that source.

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

The configuration is metro.config.js in the repository. Metro 0.87.2 and main at a87d864565, Node 26.12.1, Yarn 1.22.22, Windows 11.

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.