~~Anyone else receiving an error `Uncaught RangeError: Maximum call stack size exceeded` after one hot reload?~~

[evandrix]

~~1. Load up a standard webpack.config.js, via webpack-dev-server --config webpack.config.js --hot --progress --colors --host 0.0.0.0 --port 3000 --inline

1. To your React.js webapp, make a single change after it's completed its initial loading once.
2. Inspect the Chrome Devtools console panel, to find the following error message displayed:

[HMR] Waiting for update signal from WDS...
warning.js:36 Warning: Unknown DOM property for. Did you mean htmlFor?
client:14 [WDS] Hot Module Replacement enabled.
client:18 [WDS] App updated. Recompiling...
client:60 [WDS] App hot update...
dev-server.js:48 [HMR] Checking for updates on the server...
dev-server.js:28 [HMR] Updated modules:
dev-server.js:30 [HMR]  - 3
dev-server.js:34 [HMR] App is up to date.
bundle.js:695 Uncaught RangeError: Maximum call stack size exceeded
hotAddUpdateChunk@bundle.js:5
webpackHotUpdateCallback@bundle.js:6
webpackHotUpdateCallback@bundle.js:6
...webpackHotUpdateCallback@bundle.js:6 repeated many more times...

If someone else has encountered this, then I might provide a more detailed writeup of (redacted) diagnostics/debug logs.~~

[evandrix]

Closing issue: just realised from here that you shouldn't be doing --hot and new webpack.HotModuleReplacementPlugin() in webpack.config.js > plugins: [] section simultaneously.

[chibicode]

Ran into the same issue. Fixed by removing webpack.HotModuleReplacementPlugin() from config and keeping --hot.

[fgarcia]

I've read about doing the exact opposite, and in the walkthrough linked in the readme suggests using the Plugin, but I also fixed this problem using the command line.

[mrdulin]

@chibicode work for me!

[asidiali]

Tried removing the plugin, didn't work. Removed --hot and it worked 👍

[jdb8]

tl;dr having both --hot and the plugin installed should be fine in latest webpack-dev-server/webpack, but only if you have one copy of webpack installed. See below for why.

---

Commenting here ~5 years after this issue was first created, since this was confusing to debug and this issue thread is the first result on google for this error. I was confused because all the threads I can find seem to give conflicting information which doesn't fully match up with the official docs as of July 2019.

The docs (currently) state:

Note that webpack.HotModuleReplacementPlugin is required to fully enable HMR. If webpack or webpack-dev-server are launched with the --hot option, this plugin will be added automatically, so you may not need to add this to your webpack.config.js

Note that this doesn't mean that using both --hot and the HotModuleReplacementPlugin is incorrect, although it might not be necessary. Indeed, the code accounts for this:

webpack-dev-server/lib/utils/addEntries.js

Lines 94 to 101 in b79f523

	if (
	!config.plugins.find(
	(plugin) =>
	plugin.constructor === webpack.HotModuleReplacementPlugin
	)
	) {
	config.plugins.push(new webpack.HotModuleReplacementPlugin());
	}

- if the plugin already exists, it doesn't add it (added as part of #1612, v3.2.0). So why is there so much anecdotal evidence that removing one of --hot (or hot: true in the config) and the HotModuleReplacementPlugin solves the issue?

It's because if there's more than one copy of webpack installed in your project, depending on how you invoke webpack-dev-server, the linked code above may not work as intended. In my case, I had two copies of webpack installed:

❯ yarn list webpack
yarn list v1.13.0
warning Filtering by arguments is deprecated. Please use the pattern option instead.
├─ webpack@4.27.1
└─ <some-other-package>@31.30.4
   └─ webpack@4.29.6

which means that when that line of code above runs, it will check for plugin.constructor === webpack.HotModuleReplacementPlugin. But in my config, the value of plugin.constructor is equal to the HotModuleReplacementPlugin of webpack v4.29.6, not the one that's being checked for (v4.27.1). This code is essentially relying on webpack always resolving to the same version, otherwise it will erroneously include the HMR plugin twice, which is what causes the recursion.

In my case once I flatten my node_modules sufficiently (specifically: removing the top-level version of webpack that I don't need here, since <some-other-package> is the one actually invoking webpack-dev-server), the issue goes away 🎉

---

In terms of fixes, the check in the code could avoid referencing the specific plugin constructor by switching to a name check or something like that (e.g. plugin.constructor.name === 'HotModuleReplacementPlugin'), or find a way to require the same version of webpack that's imported in the config itself (seems harder, and is a wider issue).