HMR not working with multiple entries

[slightlyfaulty]

• Operating System: Linux
• Node Version: 14.14.0
• NPM Version: 6.14.7
• webpack Version: 5.2.0
• webpack-dev-server Version: 3.11.0
• Browser: Google Chrome

• This is a bug
• This is a modification request

Code

https://github.com/slightlyfaulty/webpack-hmr-multi-entry-repro

// webpack.config.js
...
entry: {
  first: ['./src/first.js', './src/first.css'],
  second: ['./src/second.js', './src/second.css'],
},
...

Expected Behavior

After starting the dev server, hot module replacement should work for all JS and CSS files from all webpack entries.

Actual Behavior

Hot module replacement doesn't work for all entries. Only files from the second entry are hot reloaded when changed. Files from the first entry do not get hot reloaded when changed.

For Bugs; How can we reproduce the behavior?

1. Clone repro then yarn && yarn start
2. Open http://localhost:8080/
3. Change src/first.js and src/first.css - notice they are not hot reloaded
4. Change src/second.js and src/second.css - notice they are hot reloaded

[slightlyfaulty]

Upon further testing, it seems that HMR only works for the last loaded JS bundle on the page. HMR will not work for any JS bundle loaded before it. The order of the entries in webpack.config.js does not matter.

[MohsenElgendy]

@slightlyfaulty setting optimization.runtimeChunk: "single" fixed the problem for me.

[slightlyfaulty]

Thanks for the tip @MohsenElgendy, but it's still not really ideal as you need to then load the runtime chunk alongside your other bundles. Webpack 4 handled embedding the runtime in multiple bundles at the same time no problem.

[waldronmatt]

I can also confirm optimization.runtimeChunk: "single" fixed the problem for me handling multiple bundles.

webpack.dev.config

module.exports = () => {
  const config = {
    mode: 'development',
    // Map your compiled code back to your original source code.
    devtool: 'inline-source-map',
    target: 'web',
    output: {
      filename: '[name].js',
      // specify chunck path for code splitted files
      chunkFilename: '[name].js',
    },
    devServer: {
      historyApiFallback: true,
      contentBase: path.resolve(__dirname, '../dist'),
      publicPath: '/',
      open: true,
      compress: true,
      hot: true,
      port: 8080,
    },
    plugins: [
      new ESLintPlugin({
        extensions: ['js', 'ts'],
      }),
      new StylelintPlugin(),
      new webpack.HotModuleReplacementPlugin(),
    ],
    optimization: {
      // don't minimize so we can debug
      minimize: false,
      /*
        The value 'single' instead creates a runtime file to be shared for all generated chunks.
        https://github.com/webpack/webpack-dev-server/issues/2792
      */
      runtimeChunk: "single",
    },
  };
  return merge(common('development'), config);
};

webpack.common.js

module.exports = (env) => {
  const isProduction = env === 'production';

  ...

  return {
    target: 'web',
    entry: {
      main: [
        './src/js/index.js',
        './src/ts/index.ts',
      ],
      // webpack code splitting example file
      examples: [
        './src/js/examples.js',
      ],
    },
    output: {
      path: path.join(__dirname, '../dist'),
      publicPath: '/',
    },

  ...

};

[uxsoft]

Same issue here, setting optimization.runtimeChunk: "single" fixed the problem for me as well, but I would consider this a workaround for a bug that should be fixed anyway. This certainly worked before.

[alexander-akait]

I think it fixed in v4 branch, you can try it

[slightlyfaulty]

@evilebottnawi Can't test properly because it seems writeToDisk has been removed in v4 for some reason?

Initial compilation also takes much longer than the regular build time now. Over 6 seconds compared to <2 seconds for regular build. On v3 it only takes about 2.2 seconds for the initial dev server compilation.

[alexander-akait]

It was not removed, it was moved to dev: { writeToDisk: true }

[alexander-akait]

There is no changes between v3 and v4 in perf

[slightlyfaulty]

It was not removed, it was moved to dev: { writeToDisk: true }

Aha.. that's working now, but can confirm this bug is still present. Only the last loaded bundle in the document hot reloads properly. Bundles from other entries do not hot reload at all.

Also had to explicitly disable liveReload, otherwise it live reloaded the page after every change, even though hot is enabled.

There is no changes between v3 and v4 in perf

Evidence would suggest otherwise sir. Will open an issue after release of v4 if it persists.

[alexander-akait]

@slightlyfaulty Please create reproducible test repo, it should work

[slightlyfaulty]

@alexander-akait Sure. https://github.com/slightlyfaulty/webpack-hmr-multi-entry-repro

1. yarn && yarn start - Open http://localhost:8080/
2. Change src/first.js and src/first.css - notice they are not hot reloaded, and there are some errors in the browser console
3. Change src/third.js and src/third.css - notice they are hot reloaded correctly, because they're loaded last in the page

[onetrev]

Is there a reason to avoid multiple entry points / bundles, because I'm surprised that not a ton of people are also reporting this bug? I know I need to have them. One example is I need certain things loaded in my site header and the rest at the end of the body.

One thing to note / add to the error report from @slightlyfaulty, I noticed all the console messages come in as warnings not errors, even though indeed HMR spews out a tons of warning messages like so:

[HMR] Update failed: Loading hot update chunk site_header failed.
(missing: https://localhost:3018/dist/site_header.3fb54bab211f3a92bb04.hot-update.js)
loadUpdateChunk/<@https://localhost:3018/dist/site_header.bundle.js:10391:26

[Connum]

Any news on this? I don't want to have to downgrade several packages to get it to work, and this is really slowing down development...

[pixelhuh]

Exactly the same problem and same warnings as @onetrev on webpack 5.9.18
On 4.46 HMR for multiple entries works fine.

[koen-dev]

I also encountered this issue with multiple entries. However setting optimization.runtimeChunk: "single" didn't work. I'm using multiple HtmlWebpackPlugins to serve the entries as solo applications. What is the best step for now? Move back to [email protected]?

[ghost]

Also encountered this issue. Setting optimization.runtimeChunk: "single" is not working for me. I need to output my code as library. Using [email protected] and [email protected]. Current working solution is to set hot: false and do a full page reload for every change.

[alexander-akait]

Please test https://github.com/webpack/webpack-dev-server/releases/tag/v4.0.0-beta.1, we will speed up releases, to be stable at the end of month

[slightlyfaulty]

@alexander-akait Nope no change to the issue.

#2792 (comment)

[alexander-akait]

@slightlyfaulty Found solution:

<script type="text/javascript" src="dist/runtime.js"></script>
<script type="text/javascript" src="dist/first.js"></script>
<script type="text/javascript" src="dist/second.js"></script>
<script type="text/javascript" src="dist/third.js"></script>

optimization: {
  runtimeChunk: 'single'
},

[slightlyfaulty]

@alexander-akait That solution has already been posted before.

It's more of a workaround than a solution though don't you think? Since it worked fine in Webpack 4 without needing to generate and load a runtime bundle.

[alexander-akait]

@slightlyfaulty Here are multi entries on one page... so we have multiple __webpack_require__ with HMR, each __webpack_require__ known only about own modules and HMR status, when we get update we will run multiple of them, so you can see [HMR] Update failed: ChunkLoadError: Loading hot update chunk first failed. and [HMR] Update failed: ChunkLoadError: Loading hot update chunk second failed.

[alexander-akait]

Give me time to look at this deeply, but I don't think bug in webpack-dev-server, I think it is bug with webpack here

[slightlyfaulty]

Give me time to look at this deeply, but I don't think bug in webpack-dev-server, I think it is bug with webpack here

@alexander-akait No problem. All I know is it worked fine with the Webpack 4 stack, so it's a regression one way or another.

[alexander-akait]

@slightlyfaulty Maybe it is limitation, I want to get answer from @sokra, in this case we should share ./node_modules/dev-server/client/default/index.js and ./node_modules/webpack/hot/dev-server.js and runtime code between entry points, i.e. create shared/runtime chunk(s), but without optimization.runtimeChunk, webpack doesn't do it, If we initially knew how you would use them (for example from index.html) we will apply runtimeChunk optimization by default.

https://webpack.js.org/configuration/optimization/#optimizationruntimechunk

We have warning about it:

Warning
Imported modules are initialized for each runtime chunk separately, so if you include multiple entry points on a page, beware of this behavior. You will probably want to set it to single or use another configuration that allows you to only have one runtime instance.

[stevematney]

I was able to get multiple entries working with a very hacky solution involving hijacking self["webpackHotUpdate"] with a window Proxy, utilizing a Service Worker, and which relies on another plugin that wraps the built entry bundle in a self-calling function for isolation.

It was... a lot, but eventually I got everything working smoothly. It doesn't always guarantee the updates get to the correct place if two modules are updated at the same time that have the same ID across bundles, but contain different code. This seems like a very rare case, and for our purposes, this solution is working well enough (though it's quite complex).

[ayroblu]

Hi, just wanted to follow up with whether there's an alternative solution to the runtimeChunk solution? I found that using that with monaco-editor causes it to fail to load results.
In the meantime I can set hot: false. And the main difference is that I no longer have css hot reloading.

Edit: actually I found that if I use monaco-editor-weback-plugin I don't need to do anything special, amazing

[chenwenqin]

[email protected]

only in production mode, but not in development mode, whether it is enabled or not optimization option。

My project only one entry.

[alexander-akait]

@chenwenqin Can you provide reproducible example?

[khelkun]

@alexander-akait

You can't use multiple entries on the same page, please use #2792 (comment)

Indeed it works but if I well understand, you need to include the runtimeChunk aka runtime.js before the others entry chunks.

Considering my app is actually a library used by others applications, this solution forces all dependent apps to include this new runtime.js before my library entries.

Would there be a way to embed this runtimeChunk in the chunk of the first entry of my library?

[slightlyfaulty]

@khelkun I recently discovered that if you use the dependOn option for an entry, then it will use the runtime that's embedded in the entry it depends on.

In this case you don't need to use runtimeChunk: 'single' anymore, as long as the dependOn entry is always loaded first.

[shalkauskas]

@slightlyfaulty thank you, worked great with webpack 5!

[bradyclifford]

@slightlyfaulty you wouldn't happen to have an example you could share with the dependOn working for you?

[slightlyfaulty]

@bradyclifford I've pretty much just got my entry points listed like the examples in the docs. Nothing special.

https://webpack.js.org/concepts/entry-points/#entrydescription-object

[thebat93]

I'm having a problem with HMR when Webpack has multiple entries and one of them is a service worker.

If I use runtimeChunk: 'single' hot reloading works as intended. But none of service worker's hooks runs.

I found this solution. With this service worker's hooks run, but this breaks hot reloading. When I try to update the app code I get warnings and nothing gets updated:
[HMR] Update failed: ReferenceError: document is not defined
[HMR] Update failed: ChunkLoadError: Loading hot update chunk runtime-app failed.

Has anyone faced this problem? I'm using Webpack 5 with the following options:

entry: {
  app: ['/index.tsx'],
  'service-worker': '/service-worker.js',
},
output: {
  filename: pathData => {
    if (pathData?.chunk?.name === 'service-worker') {
      return '[name].js';
    }
    return '[name].[contenthash].bundle.js';
  },
},
optimization: {
    runtimeChunk: {
      name: (entrypoint) => {
        if (entrypoint.name.startsWith("service-worker")) {
          return null;
        }
        return `runtime-${entrypoint.name}`;
      },
    },
    splitChunks: {
      chunks(chunk) {
        return chunk.name !== "service-worker";
      },
      cacheGroups: {
        default: false,
        vendors: false,
        framework: {},
        lib: {},
        commons: {},
        shared: {},
        styles: {}
      },
      maxInitialRequests: 25,
      minSize: 20000
    },
},

[thebat93]

Here is a minimal test repo with the issue: https://github.com/thebat93/sw-webpack-hmr
I mentioned solutions that I tried in webpack config file.

[develobora]

Not working for me also with multiple entries. "webpack": "^5.53.0", "webpack-dev-server": "^4.7.4".

[alexcloudstar]

@slightlyfaulty Found solution:

<script type="text/javascript" src="dist/runtime.js"></script>
<script type="text/javascript" src="dist/first.js"></script>
<script type="text/javascript" src="dist/second.js"></script>
<script type="text/javascript" src="dist/third.js"></script>

optimization: {
  runtimeChunk: 'single'
},

Thank you! is working perfectly fine.

Here is a part of my package.json (i'm doing micro-frontends btw I don't know if is matter or not because I do have the same packages installed)

"scripts": {
    "start": "webpack serve --config config/webpack.dev.js",
    "build": "webpack --config config/webpack.prod.js"
  },

devDeps:

"babel-loader": "^9.1.3",
"webpack": "^5.88.1",
"webpack-cli": "^5.1.4",
"webpack-dev-server": "^4.15.1",
"webpack-merge": "^5.9.0"
"babel-loader": "^9.1.3",
"html-webpack-plugin": "^5.5.3",
"typescript": "^5.1.6",
"@babel/core": "^7.22.8",
"@babel/plugin-transform-runtime": "^7.22.7",
"@babel/preset-env": "^7.22.7",
"@babel/preset-react": "^7.22.5",

[slightlyfaulty]

Closing this. In Webpack 5 optimization.runtimeChunk: "single" and/or dependOn/runtime should be used appropriately to control where the runtime is embedded. Otherwise each entry contains a runtime resulting in this issue.