Why not use it?"@next/react-refresh-utils"

Why not use it?“@next/react-refresh-utils”

        const ReactRefreshWebpackPlugin =
            require("@next/react-refresh-utils/ReactRefreshWebpackPlugin").default;
        config.entry = [
            require.resolve("@next/react-refresh-utils/runtime"),
            ...config.entry,
        ];
        config.plugins = [new ReactRefreshWebpackPlugin(), ...config.plugins];
        config.module.rules = [
            {
                test: /\.(tsx|ts|js|mjs|jsx)$/,
                include: [srcfoldepath],
                exclude: [/node_modules/],
                use: [require.resolve("@next/react-refresh-utils/loader")],
            },
            ...config.module.rules,
        ];

[pmmmwh]

Short answer: This plugin exists way before Next.js implemented RR and we address different concerns even though the core functionality is similar. If you want something batteries included, then it’s probably this plugin.

Long answer: The Next.js version of fast refresh utilities spawned from their need to implement Webpack HMR invalidation. The team from Vercel and I (and Dan) were in touch and they decided to implement their new utilities, with close integration with their error overlay, based on the runtime implemented in this plugin back then.

Since then this plugin has evolved and diverged to provide more features (e.g. WHM/WPS support, native ESM, top level await (experimental), fully plug and play overlay), we’ve re-written core parts to support a wider spectrum of build setups, and we also try to be as batteries included as possible - we will do the entry injection, loader injection, etc. for you by default.

I guess it really boils down to choice, if your build setup is similar to what Next.js is running and you don’t need much customisation, you could use what they have provided. However, it should also be noted that I believe they built the set of utilities to suit their specific use case, and your mileage may vary.

An addendum - you can also configure this plugin to how you’ve configured the Next.js utilities, if you prefer to wire up everything on your own:

const ReactRefreshWebpackPlugin =
            require("@pmmmwh/react-refresh-webpack-plugin");

config.entry = [
  require.resolve("@pmmmwh/react-refresh-webpack-plugin/client/ReactRefrsshEntry"),
  ...config.entry,
];
config.plugins = [
  new ReactRefreshWebpackPlugin(),
  ...config.plugins,
];
config.module.rules = [
  {
    test: /\.(mjs|[jt]sx?)$/,
    include: srcPath,
    exclude: /node_modules/,
    use: [
      require.resolve("@pmmmwh/react-refresh-webpack-plugin/loader"),
    ],
  },
  ...config.module.rules,
];

[masx200]

Ok that is interesting, I am using it with webpack v5.51.0. I, however, start the dev server with the dev-middleware directly.

“webpack”: “^5.44.0”, “webpack-cli”: “^4.7.2”, “webpack-dev-server”: “^3.11.2”,

I started it with the "

webpack serve --config=webpack.config.js --mode=development

" method. The configuration file is like this.

https://github.com/masx200/webpack-react-vue-spa-awesome-config/blob/1e43822140b51deb778684ea677cdd9035ea9c39/lib/config.ts#L632

https://github.com/masx200/webpack-react-vue-spa-awesome-config/blob/1e43822140b51deb778684ea677cdd9035ea9c39/release/config/webpack.config.js#L1

https://github.com/masx200/webpack-react-vue-spa-awesome-config/blob/1e43822140b51deb778684ea677cdd9035ea9c39/webpack.config.js#L5