[Bug]: rspack hmr hit error when version > 0.5.1 about rspack HOT 29 CLOSED

也遇到这个问题了，[email protected]使用react会刷新整个页面

不仅仅是hmr失效，还有hmr失效导致的内存泄漏问题，dev几个小时网页占用4个g，每天都是。
难道字节内部用lazy import用的少，还是说开发环境还是在用webpack，rspack仅用来build提速。
rolldown到今年年底应该prod ready了，到时vite的生态+rolldown的速度，rspack得加把劲啊，这问题这么久了，竟然还不排期。

很抱歉未能及时响应，我不确定你的场景是否和上面 babel-loader 的问题一致，能否提供一个可以复现的 demo 以排查问题？

事实上，一直用的都是swc-loader，要搞清楚为啥hmr在0.5.1之后变这样了（更新页面闪烁+内存泄漏（开不开module都泄漏））得回过头去整体看一下是改动了什么导致的。

另外，内存泄漏可能与hmr失效+Activity(Offscreen有关)。

至于reprod repo，目前为止，只要用react动态加载（官方默认配置）都会在更新时闪烁，而且0.5.1之前的hmr是能命中更改的组件的（控制台打印的），现在只会打印lazyelement.tsx出现变化，这个路径无疑是错的。

0.5.1 和 0.5.2 之间的提交比较多，很难直接通过代码确定哪个变动导致的问题。由于 HMR 整个链路非常复杂，需要从构建（包括注入 loader 和 transform loader）到 Webpack Runtime 到 React Refresh Plugin Runtime 到 React Refresh Runtime 到 React，这里面任何一步没有走通都会导致页面刷新。

上面外国友人的项目我在本地加上 babel plugin 后跑起来 HMR 是正常的，我也尝试了用 builtin:swc-loader 和 swc-loader 也是正常的。根据你的截图里面反馈的错误信息，似乎是和 context module 场景有关，所以可能是是一个组合问题。我自己尝试了一下 context module 本地也能正常工作。

所以最好还是能提供一个复现的例子，能复现的话我就能排查是 0.5.1 到 0.5.2 中间的哪个变更导致的。即使是官方的例子，也请黏贴一下官方的用例链接，我好按照它的场景来复现

from rspack.

I have a repro case here: https://github.com/bostondv/rspack-react-refresh/tree/3455ec8873333a8890ef46f82493e5990cbd991f

In this example, its not reproducible on every file change but here are steps:

1. Start the server and increment both counters but clicking the buttons
2. Make any simple change to App.tsx
3. Make any simple change to Page.tsx
4. Repeat step 3 a few times

Eventually the state for the "Lazy Count" (which is a Lazy imported component) will be lost.

Its difficult to observe besides the state what's going on, but in our actual app, the entire tree from the first lazy import is reloaded and loses state. Anything above the lazy import fast refresh works fine and retain state.

from rspack.

I have a repro case here: https://github.com/bostondv/rspack-react-refresh/tree/3455ec8873333a8890ef46f82493e5990cbd991f

In this example, its not reproducible on every file change but here are steps:

1. Start the server and increment both counters but clicking the buttons
2. Make any simple change to App.tsx
3. Make any simple change to Page.tsx
4. Repeat step 3 a few times

Eventually the state for the "Lazy Count" (which is a Lazy imported component) will be lost.

Its difficult to observe besides the state what's going on, but in our actual app, the entire tree from the first lazy import is reloaded and loses state. Anything above the lazy import fast refresh works fine and retain state.

Sorry for the delay. React refresh requires a Babel plugin to handle state updates in some scenarios, the '@rspack/plugin-react-refresh' plugin provided by rspack only supports builtins:swc-loader.

I found that your project uses 'babel-loader', so you will need to use the official Babel plugin. This issue can be resolved by adding import.meta.resolve('react-refresh/babel') to the options.plugins of babel-loader. Here is a demo

from rspack.

After adding react-refresh/babel and with @rspack/plugin-react-refresh, the hmr of that simple example do not trigger full reload but the state is indeed lost. I will try to solve the issue of state loss. If the hmr failure and the full reload in your project is not caused by this issue, it may be necessary to provide another reproduction project(or update this one). If I can reproduce the issue, there will be a way to find out which modification between 0.5.1 and 0.5.2 caused it.

I tested this in webpack + react-refresh-webpack-plugin and encountered the same issue. Seems to be caused by the update strategy (dom diff) of React. When adding a new dom before the page node, the state of the page node should be applied to the new node because it is the first node. And if you add a key to the page node just like , the page will retain its state because dom diff can recognize it and treat it as the same node across HMR rendering.

Thanks for checking. I checked my repro example again on 0.5.1 after adding react-refresh/babel and same issue there.

Our actual app does have react-refresh/babel configured and fully reloads and loses state in the tree up to the top most React dynamic imported component on any change. I'll see if I can get any better repro example. It could be a combination of problems like you mentioned, we have a large complex app.

from rspack.

也遇到这个问题了，[email protected]使用react会刷新整个页面

不仅仅是hmr失效，还有hmr失效导致的内存泄漏问题，dev几个小时网页占用4个g，每天都是。
难道字节内部用lazy import用的少，还是说开发环境还是在用webpack，rspack仅用来build提速。
rolldown到今年年底应该prod ready了，到时vite的生态+rolldown的速度，rspack得加把劲啊，这问题这么久了，竟然还不排期。

很抱歉未能及时响应，我不确定你的场景是否和上面 babel-loader 的问题一致，能否提供一个可以复现的 demo 以排查问题？

事实上，一直用的都是swc-loader，要搞清楚为啥hmr在0.5.1之后变这样了（更新页面闪烁+内存泄漏（开不开module都泄漏））得回过头去整体看一下是改动了什么导致的。
另外，内存泄漏可能与hmr失效+Activity(Offscreen有关)。
至于reprod repo，目前为止，只要用react动态加载（官方默认配置）都会在更新时闪烁，而且0.5.1之前的hmr是能命中更改的组件的（控制台打印的），现在只会打印lazyelement.tsx出现变化，这个路径无疑是错的。

0.5.1 和 0.5.2 之间的提交比较多，很难直接通过代码确定哪个变动导致的问题。由于 HMR 整个链路非常复杂，需要从构建（包括注入 loader 和 transform loader）到 Webpack Runtime 到 React Refresh Plugin Runtime 到 React Refresh Runtime 到 React，这里面任何一步没有走通都会导致页面刷新。

上面外国友人的项目我在本地加上 babel plugin 后跑起来 HMR 是正常的，我也尝试了用 builtin:swc-loader 和 swc-loader 也是正常的。根据你的截图里面反馈的错误信息，似乎是和 context module 场景有关，所以可能是是一个组合问题。我自己尝试了一下 context module 本地也能正常工作。

所以最好还是能提供一个复现的例子，能复现的话我就能排查是 0.5.1 到 0.5.2 中间的哪个变更导致的。即使是官方的例子，也请黏贴一下官方的用例链接，我好按照它的场景来复现

https://github.com/1yasa/rspack_reproduce

我尝试复现，但v0.5.8已无法复现，不过hmr闪烁依然存在（一个巨型的全是lazy import的项目），我注意到在更新时hmr“命中”了两次，一次是更改的组件处，一次直接回溯到了lazyElement，就是第二次的回溯导致了闪烁：

from rspack.

can you try this version 0.5.8-canary-0c655a5-20240325085109

from rspack.

sorry, that's a small issue, try 0.5.9

Tested 0.5.9 and appears to fix the issue for me. Thank you!

from rspack.

@LingyuCoder @JSerFeng fixed, thanks.

from rspack.

In v0.5.5, LazyElement hit cache success(no recompile all module), but hmr missed(page was flash and refreshed).

Seems like hit path is wrong, just hit cache success by import maps.

from rspack.

I've also noticed similar issue in our app since 0.5.2 but we don't use lazy. We use our own homegrown fork of react-loadable.

In 0.5.1 and earlier, file change will successfully update the page and retain React state.

In 0.5.2 and later (tested up to 0.5.5), file change will cause full page reload and React state loss.

from rspack.

也遇到这个问题了，[email protected]使用react会刷新整个页面

from rspack.

也遇到这个问题了，[email protected]使用react会刷新整个页面

不仅仅是hmr失效，还有hmr失效导致的内存泄漏问题，dev几个小时网页占用4个g，每天都是。

难道字节内部用lazy import用的少，还是说开发环境还是在用webpack，rspack仅用来build提速。

rolldown到今年年底应该prod ready了，到时vite的生态+rolldown的速度，rspack得加把劲啊，这问题这么久了，竟然还不排期。

from rspack.

也遇到这个问题了，[email protected]使用react会刷新整个页面

不仅仅是hmr失效，还有hmr失效导致的内存泄漏问题，dev几个小时网页占用4个g，每天都是。

难道字节内部用lazy import用的少，还是说开发环境还是在用webpack，rspack仅用来build提速。

rolldown到今年年底应该prod ready了，到时vite的生态+rolldown的速度，rspack得加把劲啊，这问题这么久了，竟然还不排期。

很抱歉未能及时响应，我不确定你的场景是否和上面 babel-loader 的问题一致，能否提供一个可以复现的 demo 以排查问题？

from rspack.

也遇到这个问题了，[email protected]使用react会刷新整个页面

很抱歉未能及时响应，刷新页面一般是遇到了 HMR 过程中发生了错误或者模块树冒泡过程未能被捕获，情况比较复杂，能否提供一个可以复现的 demo 以排查问题？

from rspack.

Sorry for the delay. React refresh requires a Babel plugin to handle state updates in some scenarios, the '@rspack/plugin-react-refresh' plugin provided by rspack only supports builtins:swc-loader.

I found that your project uses 'babel-loader', so you will need to use the official Babel plugin. This issue can be resolved by adding import.meta.resolve('react-refresh/babel') to the options.plugins of babel-loader. Here is a demo

Thanks @LingyuCoder, I'm aware of react-refresh/babel. In our project we use it but I forgot to include it in this simple repro example... I did see we also use @rspack/plugin-react-refresh at the same time in our project, but I don't think its the cause of the error.

With [email protected] HMR works perfectly in our app. From [email protected] and higher it does not work (all lazy loadables fully reload on file change). So I don't think it is related to the babel plugin.

from rspack.

@LingyuCoder with babel, react-refresh/babel and @rspack/plugin-react-refresh are required? If I remove @rspack/plugin-react-refresh the example does not start.

I've updated the example with the babel plugin and can still reproduce the issue. However, the repro steps are a bit different now:

1. Start the app
2. Click the buttons to increment both counts
3. Make a change to the JSX in src/App.jsx such as adding a <div /> before the <Page />
4. Save
5. Lazy Count button state will reset

This is reproducible 100% of the time.

Also to note, changing just a string in the App.jsx JSX maintains state (eg. <h1>Hello, World</h1> to <h1>Hello</h1>), so not all changes appear to cause the error.

from rspack.

Also can repro above with swc-loader, and latest 0.5.8

from rspack.

也遇到这个问题了，[email protected]使用react会刷新整个页面

不仅仅是hmr失效，还有hmr失效导致的内存泄漏问题，dev几个小时网页占用4个g，每天都是。

难道字节内部用lazy import用的少，还是说开发环境还是在用webpack，rspack仅用来build提速。

rolldown到今年年底应该prod ready了，到时vite的生态+rolldown的速度，rspack得加把劲啊，这问题这么久了，竟然还不排期。

很抱歉未能及时响应，我不确定你的场景是否和上面 babel-loader 的问题一致，能否提供一个可以复现的 demo 以排查问题？

事实上，一直用的都是swc-loader，要搞清楚为啥hmr在0.5.1之后变这样了（更新页面闪烁+内存泄漏（开不开module都泄漏））得回过头去整体看一下是改动了什么导致的。

另外，内存泄漏可能与hmr失效+Activity(Offscreen有关)。

至于reprod repo，目前为止，只要用react动态加载（官方默认配置）都会在更新时闪烁，而且0.5.1之前的hmr是能命中更改的组件的（控制台打印的），现在只会打印lazyelement.tsx出现变化，这个路径无疑是错的。

from rspack.

with babel, react-refresh/babel and @rspack/plugin-react-refresh are required? If I remove @rspack/plugin-react-refresh the example does not start.

When using Babel, the react-refresh/babel is not required, but it is indeed recommended, which will do some transformation at compile time, making the changes of react methods recognizable, thereby reducing page refreshes caused by component re-rendering failure.

And it is also implemented in builtin:swc-loader or swc-loader, you can enable it by jsc.transform.react.refresh.

The @rspack/plugin-react-refresh is required because it injects the code (including the $RefreshSig$) for collecting HMR change information within each module and transport them to the react-refresh runtime for component re-rendering, and also it injects some runtime code. React refresh can not work without it in rspack. This is same with react-refresh-webpack-plugin

After adding react-refresh/babel and with @rspack/plugin-react-refresh, the hmr of that simple example do not trigger full reload but the state is indeed lost. I will try to solve the issue of state loss. If the hmr failure and the full reload in your project is not caused by this issue, it may be necessary to provide another reproduction project(or update this one). If I can reproduce the issue, there will be a way to find out which modification between 0.5.1 and 0.5.2 caused it.

from rspack.

I've updated the example with the babel plugin and can still reproduce the issue. However, the repro steps are a bit different now:

1. Start the app
2. Click the buttons to increment both counts
3. Make a change to the JSX in src/App.jsx such as adding a <div /> before the <Page />
4. Save
5. Lazy Count button state will reset

This is reproducible 100% of the time.

I tested this in webpack + react-refresh-webpack-plugin and encountered the same issue. Seems to be caused by the update strategy (dom diff) of React. When adding a new dom before the page node, the state of the page node should be applied to the new node because it is the first node. And if you add a key to the page node just like <Page key="xxx"/>, the page will retain its state because dom diff can recognize it and treat it as the same node across HMR rendering.

from rspack.

https://github.com/1yasa/rspack_reproduce

在这个项目下尝试了 0.5.8 和 0.5.3 版本，修改 modules 和 components 下的内容，未能复现 full reload 的问题。闪烁的问题在修改 components/LazyElement 和 components/OffscreenOutlet 能够稳定复现，但我尝试了一下使用 webpack + react-refresh-webpack-plugin + swc-loader 也同样出现闪烁。

我在你提供的 demo 上删去了大部分代码，仅保留一个 LazyComponent，修改 LazyComponent 内的 dom 节点依然会触发闪烁，但修改 A 则不会。通过时间打点发现，HMR完成后组件也很快就被获取，但组件获取后到渲染完成有一个明显的体感延时。这似乎是 react 内部的更新机制导致。

你也可以在这个项目尝试一下，在 npm run dev:w 启动 webpack dev server，移除这一行代码即可：https://github.com/LingyuCoder/react-refresh-hmr-bug/blob/master/components/LazyElement.tsx#L19。

如果是大型项目下出现 Full Reload 可以通过尝试看看这些流程是否正常，修改一个文件后：

1. 是否开启了 newTreeshaking，目前 newTreeshaking 未兼容增量构建，这个问题由于涉及架构，目前正在修正
2. hot-update.json 是否拉取成功，且其内部 c 字段的项目数量较少，仅包含修改文件所相关的 chunk 的 id

• 若 chunk 较多，可以尝试关闭 optimization.splitChunks

3. hot-update.js 是否拉取成功，且内部仅包含锁修改的文件编译后的结果

• 若包含大量上下游模块，可以尝试关闭 optimization.splitChunks
• 若包含 node_modules 下模块，可以尝试将对应模块加入 exclude

from rspack.

https://github.com/1yasa/rspack_reproduce

在这个项目下尝试了 0.5.8 和 0.5.3 版本，修改 modules 和 components 下的内容，未能复现 full reload 的问题。闪烁的问题在修改 components/LazyElement 和 components/OffscreenOutlet 能够稳定复现，但我尝试了一下使用 webpack + react-refresh-webpack-plugin + swc-loader 也同样出现闪烁。

我在你提供的 demo 上删去了大部分代码，仅保留一个 LazyComponent，修改 LazyComponent 内的 dom 节点依然会触发闪烁，但修改 A 则不会。通过时间打点发现，HMR完成后组件也很快就被获取，但组件获取后到渲染完成有一个明显的体感延时。这似乎是 react 内部的更新机制导致。

你也可以在这个项目尝试一下，在 npm run dev:w 启动 webpack dev server，移除这一行代码即可：https://github.com/LingyuCoder/react-refresh-hmr-bug/blob/master/components/LazyElement.tsx#L19。

如果是大型项目下出现 Full Reload 可以通过尝试看看这些流程是否正常，修改一个文件后：

1. 是否开启了 newTreeshaking，目前 newTreeshaking 未兼容增量构建，这个问题由于涉及架构，目前正在修正
2. hot-update.json 是否拉取成功，且其内部 c 字段的项目数量较少，仅包含修改文件所相关的 chunk 的 id

• 若 chunk 较多，可以尝试关闭 optimization.splitChunks

3. hot-update.js 是否拉取成功，且内部仅包含锁修改的文件编译后的结果

• 若包含大量上下游模块，可以尝试关闭 optimization.splitChunks
• 若包含 node_modules 下模块，可以尝试将对应模块加入 exclude

In our app I checked hot-update.json between 0.5.1 and 0.5.8.

With 0.5.1 it always maintains state and only updates the edited file.

With 0.5.8 it sometimes maintains state and sometimes loses state and updates several files in the tree.

I don't know if there's a deterministic kind of change that causes the issue. I only made simple one line changes in a React component. in both versions.

Our app is not using new treeshaking and it does use split chunks.

optimization: {
    moduleIds: 'deterministic',
    chunkIds: 'deterministic',
    splitChunks: {
      chunks: 'all',
      maxAsyncRequests: 5,
      maxInitialRequests: 5,
      minChunks: 1,
      minSize: 50000,
      name: false,
    },
  },

rspack 0.5.1:

console output:

[HMR] connected
client.js:240 [HMR] bundle rebuilding
client.js:249 [HMR] bundle rebuilt in 8145ms
process-update.js:51 [HMR] Checking for updates on the server...
process-update.js:125 [HMR] Updated modules:
process-update.js:127 [HMR]  - ../../../client/store/pages/home/pages/home/components/StoreForward/StoreForwardTruncationList/TruncationList.tsx
process-update.js:131 [HMR] App is up to date.

hot-update.json:

{
    "c": [
        "26896",
        "1484"
    ],
    "r": [
        "38749",
        "91560",
        "81914",
        "21972",
        "97215",
        "35291",
        "44902",
        "53948",
        "412",
        "65490",
        "65789",
        "86550",
        "47599",
        "21881",
        "12126",
        "27435",
        "95568",
        "3011",
        "33498",
        "2030",
        "20196",
        "96185",
        "69106",
        "740"
    ],
    "m": []
}

rspack 0.5.8:

console output:

[HMR] connected
client.js:240 [HMR] bundle rebuilding
client.js:249 [HMR] bundle rebuilt in 1250ms
process-update.js:51 [HMR] Checking for updates on the server...
process-update.js:125 [HMR] Updated modules:
process-update.js:127 [HMR]  - ../../../client/store/pages/home/pages/home/components/StoreForward/StoreForwardTruncationList/TruncationList.tsx
process-update.js:127 [HMR]  - ../../../client/store/pages/shop/routes.ts
process-update.js:127 [HMR]  - ../../../client/store/pages/home/HomeWithStorefrontRedirect.tsx
process-update.js:127 [HMR]  - ../../../client/store/storefront/shared/preloader/StorefrontPreloader.tsx
process-update.js:127 [HMR]  - ../../../client/store/pages/shop/Shop.tsx
process-update.js:127 [HMR]  - ../../../client/store/platform/shared/routing/globalAppRoutes.ts
process-update.js:127 [HMR]  - ../../../client/store/platform/shared/AppRouter.tsx
process-update.js:131 [HMR] App is up to date.

hot-update.json:

{
  "c": [
      "5643",
      "26896",
      "1484"
  ],
  "r": [
      "35291",
      "91560",
      "81914",
      "97215",
      "21972",
      "44902",
      "52336",
      "21881",
      "86550",
      "12126",
      "27435",
      "95568",
      "2030",
      "69014",
      "20196",
      "96185",
      "69106",
      "740"
  ],
  "m": []
}

from rspack.

https://github.com/1yasa/rspack_reproduce

在这个项目下尝试了 0.5.8 和 0.5.3 版本，修改 modules 和 components 下的内容，未能复现 full reload 的问题。闪烁的问题在修改 components/LazyElement 和 components/OffscreenOutlet 能够稳定复现，但我尝试了一下使用 webpack + react-refresh-webpack-plugin + swc-loader 也同样出现闪烁。
我在你提供的 demo 上删去了大部分代码，仅保留一个 LazyComponent，修改 LazyComponent 内的 dom 节点依然会触发闪烁，但修改 A 则不会。通过时间打点发现，HMR完成后组件也很快就被获取，但组件获取后到渲染完成有一个明显的体感延时。这似乎是 react 内部的更新机制导致。
你也可以在这个项目尝试一下，在 npm run dev:w 启动 webpack dev server，移除这一行代码即可：https://github.com/LingyuCoder/react-refresh-hmr-bug/blob/master/components/LazyElement.tsx#L19。
如果是大型项目下出现 Full Reload 可以通过尝试看看这些流程是否正常，修改一个文件后：

1. 是否开启了 newTreeshaking，目前 newTreeshaking 未兼容增量构建，这个问题由于涉及架构，目前正在修正
2. hot-update.json 是否拉取成功，且其内部 c 字段的项目数量较少，仅包含修改文件所相关的 chunk 的 id

• 若 chunk 较多，可以尝试关闭 optimization.splitChunks

3. hot-update.js 是否拉取成功，且内部仅包含锁修改的文件编译后的结果

• 若包含大量上下游模块，可以尝试关闭 optimization.splitChunks
• 若包含 node_modules 下模块，可以尝试将对应模块加入 exclude

In our app I checked hot-update.json between 0.5.1 and 0.5.8.

With 0.5.1 it always maintains state and only updates the edited file.

With 0.5.8 it sometimes maintains state and sometimes loses state and updates several files in the tree.

I don't know if there's a deterministic kind of change that causes the issue. I only made simple one line changes in a React component. in both versions.

Our app is not using new treeshaking and it does use split chunks.

optimization: {
    moduleIds: 'deterministic',
    chunkIds: 'deterministic',
    splitChunks: {
      chunks: 'all',
      maxAsyncRequests: 5,
      maxInitialRequests: 5,
      minChunks: 1,
      minSize: 50000,
      name: false,
    },
  },

rspack 0.5.1:

console output:

[HMR] connected
client.js:240 [HMR] bundle rebuilding
client.js:249 [HMR] bundle rebuilt in 8145ms
process-update.js:51 [HMR] Checking for updates on the server...
process-update.js:125 [HMR] Updated modules:
process-update.js:127 [HMR]  - ../../../client/store/pages/home/pages/home/components/StoreForward/StoreForwardTruncationList/TruncationList.tsx
process-update.js:131 [HMR] App is up to date.

hot-update.json:

{
    "c": [
        "26896",
        "1484"
    ],
    "r": [
        "38749",
        "91560",
        "81914",
        "21972",
        "97215",
        "35291",
        "44902",
        "53948",
        "412",
        "65490",
        "65789",
        "86550",
        "47599",
        "21881",
        "12126",
        "27435",
        "95568",
        "3011",
        "33498",
        "2030",
        "20196",
        "96185",
        "69106",
        "740"
    ],
    "m": []
}

rspack 0.5.8:

console output:

[HMR] connected
client.js:240 [HMR] bundle rebuilding
client.js:249 [HMR] bundle rebuilt in 1250ms
process-update.js:51 [HMR] Checking for updates on the server...
process-update.js:125 [HMR] Updated modules:
process-update.js:127 [HMR]  - ../../../client/store/pages/home/pages/home/components/StoreForward/StoreForwardTruncationList/TruncationList.tsx
process-update.js:127 [HMR]  - ../../../client/store/pages/shop/routes.ts
process-update.js:127 [HMR]  - ../../../client/store/pages/home/HomeWithStorefrontRedirect.tsx
process-update.js:127 [HMR]  - ../../../client/store/storefront/shared/preloader/StorefrontPreloader.tsx
process-update.js:127 [HMR]  - ../../../client/store/pages/shop/Shop.tsx
process-update.js:127 [HMR]  - ../../../client/store/platform/shared/routing/globalAppRoutes.ts
process-update.js:127 [HMR]  - ../../../client/store/platform/shared/AppRouter.tsx
process-update.js:131 [HMR] App is up to date.

hot-update.json:

{
  "c": [
      "5643",
      "26896",
      "1484"
  ],
  "r": [
      "35291",
      "91560",
      "81914",
      "97215",
      "21972",
      "44902",
      "52336",
      "21881",
      "86550",
      "12126",
      "27435",
      "95568",
      "2030",
      "69014",
      "20196",
      "96185",
      "69106",
      "740"
  ],
  "m": []
}

Without new treeshaking, you can try to disable the following configurations: optimization.sideEffects and optimization.splitChunks - to ascertain if the chunks in hot-update.json can return to normal.

And also you can check which module changes in chunk "5643", you can set optimization.chunkIds="named" and optimization.moduleIds="name" to get the module request. Sometimes the modules in a chunk may change due to hash changes.

If new modules appear, there may be a bug sideEffects analysis. If modules have been moved (from one chunk to another), there may be a bug in splitChunks.

from rspack.

Without new treeshaking, you can try to disable the following configurations: optimization.sideEffects and optimization.splitChunks - to ascertain if the chunks in hot-update.json can return to normal.

And also you can check which module changes in chunk "5643", you can set optimization.chunkIds="named" and optimization.moduleIds="name" to get the module request. Sometimes the modules in a chunk may change due to hash changes.

If new modules appear, there may be a bug sideEffects analysis. If modules have been moved (from one chunk to another), there may be a bug in splitChunks.

Setting optimization.splitChunks=false appears to fix the issue. Setting optimization.sideEffects=false had no effect.

Setting optimization.chunkIds="named" and optimization.moduleIds="named" makes the problem worse, many more modules are included in the hot update for the same file change. So its difficult to debug the issue with named chunks and modules...

With split chunks enabled, the issue is intermittent and might be related to what is changed. Most times changes trigger the issue, but sometimes simple changes work fine. Its not deterministic though.

from rspack.

Keeping optimization.splitChunks enabled and only changing optimization.splitChunks.minSize from 50000 to 20000 in my config appears to fix the issue, at least in the one case I'm testing with. With minSize=50000 the issue is intermittent.

Could this min size of chunks be exposing a bug with splitChunks?

from rspack.

Keeping optimization.splitChunks enabled and only changing optimization.splitChunks.minSize from 50000 to 20000 in my config appears to fix the issue, at least in the one case I'm testing with. With minSize=50000 the issue is intermittent.

Could this min size of chunks be exposing a bug with splitChunks?

cc @JSerFeng , seems that relate to the unstable sort in find_graph_roots

from rspack.

Unable to test due to error starting dev server:

node_modules/@rspack/core/dist/Compiler.js:504
    __classPrivateFieldSet(this, _Compiler_instance, new instanceBinding.Rspack(rawOptions, this.builtinPlugins, {
                                                     ^

Error: Missing field `afterProcessAssets`
    at Compiler._Compiler_getInstance (node_modules/@rspack/core/dist/Compiler.js:504:54)
    at Compiler.build (node_modules/@rspack/core/dist/Compiler.js:379:87)
    at node_modules/@rspack/core/dist/Compiler.js:427:18
    at Hook.eval [as callAsync] (eval at create (node_modules/@rspack/core/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:6:1)
    at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (node_modules/@rspack/core/node_modules/tapable/lib/Hook.js:18:14)
    at Compiler.compile (node_modules/@rspack/core/dist/Compiler.js:421:34)
    at node_modules/@rspack/core/dist/Watching.js:263:23
    at Hook.eval [as callAsync] (eval at create (node_modules/@rspack/core/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:15:1)
    at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (node_modules/@rspack/core/node_modules/tapable/lib/Hook.js:18:14)
    at Watching._Watching_go (node_modules/@rspack/core/dist/Watching.js:253:34) {
  code: 'InvalidArg'
}

Node.js v18.19.0

from rspack.

Unable to test due to error starting dev server:

node_modules/@rspack/core/dist/Compiler.js:504
    __classPrivateFieldSet(this, _Compiler_instance, new instanceBinding.Rspack(rawOptions, this.builtinPlugins, {
                                                     ^

Error: Missing field `afterProcessAssets`
    at Compiler._Compiler_getInstance (node_modules/@rspack/core/dist/Compiler.js:504:54)
    at Compiler.build (node_modules/@rspack/core/dist/Compiler.js:379:87)
    at node_modules/@rspack/core/dist/Compiler.js:427:18
    at Hook.eval [as callAsync] (eval at create (node_modules/@rspack/core/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:6:1)
    at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (node_modules/@rspack/core/node_modules/tapable/lib/Hook.js:18:14)
    at Compiler.compile (node_modules/@rspack/core/dist/Compiler.js:421:34)
    at node_modules/@rspack/core/dist/Watching.js:263:23
    at Hook.eval [as callAsync] (eval at create (node_modules/@rspack/core/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:15:1)
    at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (node_modules/@rspack/core/node_modules/tapable/lib/Hook.js:18:14)
    at Watching._Watching_go (node_modules/@rspack/core/dist/Watching.js:253:34) {
  code: 'InvalidArg'
}

Node.js v18.19.0

cc @ahabhgk , is this relate to the hook refactoring?

from rspack.

Unable to test due to error starting dev server:

sorry, that's a small issue, try 0.5.9

from rspack.