react-refresh-webpack-plugin: Error: "Hot Module Replacement (HMR) is not enabled!"

I’m getting this error:

[React Refresh] Hot Module Replacement (HMR) is not enabled! React Refresh requires HMR to function properly.

I’m using electron-forge to drive the webpack config, and it uses webpack-dev-server with hot: true internally. Apparently, there’s a kind of an init ordering issue, but react-refresh-webpack-plugin wrongly detects that hot reload is not enables.

A simple demonstration of the incorrectness of this behavior is adding new webpack.HotModuleReplacementPlugin() makes the error go away and the page to load, but upon the refresh the typical stack overflow error caused by two instances of hot reload plugin running occurs.

Our setup worked correctly before the update, this seems like a bug. It would be great to have an option to opt-out of this check entirely.

Unfortunately, disabling hot at the webpack-dev-server end is not an option for us, since it’s under control of the electron-forge.

Webpack we’re using is v4. Version 0.3.3 works, version 0.4.1 has this issue.

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 17 (9 by maintainers)

Most upvoted comments

I got it to work. For some reason I had accidentally removed const webpackHotMiddleware = require('webpack-hot-middleware') as I thought it part of the react-hot-loader package, which I in fact was replacing.

Perhaps the guide could state the importance of enabling HMR, as I did not get it to work by just blindly following it?

webpack.config.js (dev)

const webpack = require('webpack');
const ReactRefreshPlugin = require('@pmmmwh/react-refresh-webpack-plugin');

...

entry: {
    app: ['webpack-hot-middleware/client'],
},

...

plugins: [
    new webpack.HotModuleReplacementPlugin(),
    new ReactRefreshPlugin(),
],

silkfire on Aug 11, 2020

I was debating to either use forceEnable as a way to suppress checks, or just add a forceSuppressErrors flag. Maybe we could go with the latter then.

pmmmwh on Aug 7, 2020

I make it work with a patch that comments out the checks. I was getting a lot of HMR warning messages about incorrcect (or unexpected) errors. I’m not sure what was causing it, but it was a code with a gross hack, so I didn’t create an issue for that. When I have time to continue the investigation - I’ll try to debug it.

I think it might have something to do with mismatched conditions inside the prerender script, ouch.

Also, I figured there must be a webpack plugin that conditionally inserts other plugins based on a predicate over the context.

This is actually not very safe because all plugins should have been added before the compilation starts (cause after that hooks will run in order and will not re-fire) … (which is also why we don’t insert HMR automatically because some other integration might do it programmatically)

pmmmwh on Aug 7, 2020

Adding a preload script should allow you to reproduce this issue. Not sure how to work around this though. Maybe allow user to pass a predicate ((context) => bool) to determine whether to enable plugin or not? This seems like an inflexibility of the electron-forge that we can’t have separate webpack plugins for renderer and preload bundles.

This should be of interest to you.

In the mean time though, I might just add a way to disable checks, but do note that with disabled checks we cannot guarantee stuff will work (esp. HMR is not enabled for the preload script). I don’t think any errors will arise, it’s just some bloat no-op if branches (hopefully)

pmmmwh on Aug 3, 2020