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

オープン
  • 何か問題がありますか？
#2,133 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
javascript, react-native
領域
backend, devtools

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
JavaScript
スター
5.7k
フォーク
711
平均マージ
2日 18時間
マージ済み PR（30日）
66

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

react/metro のほかの issue

react/metro の issue をすべて見る

似ている issue

JavaScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。