reload browser when hash is changed but no modules was updated

@alexander-akait

@alexander-akait Thanks for the feedback!

I have completely removed the staticOptions and setup the directory for my static files. I also removed wds + src watch content base (old) option. After that, all edited twig files triggers a new compilation, but still no browser reload. With hot: false, it works, weird 🤔

Then I have set the watchFiles option to ['src/**/*.twig'] with hot: true: it works!
Every file change trigger a compilation and browser reload.

Is that configuration looks fine to you or should I share my private repo with you for further check?
Thanks a lot mate 😉

Originally posted by @xavierfoucrier in #2758 (comment)

ref: webpack/copy-webpack-plugin#674

@xavierfoucrier

@xavierfoucrier but here some limitations, if you have copy-webpack-plugin or plugins which added files to compilation, hash was changed too, but not each file require reload browser...

Sure. In my case I will probably drop the copy-webpack-plugin, for now I will stick with the watchFiles option and wait to test this feature to be implemented.

@alexander-akait

@alexander-akait
I'd like to ask a digression. If we just want to enable Live Reload, how to configure it? Like this?

module.exports = {
  //...
  devServer: {
    static: {
      directory: path.join(__dirname, "dist"),,
      // watch: true,
    },
    watchFiles: ["src/**/*"],
    hot: false,
  },
};

The above configuration works, but I still have a few questions:

Do we need to set watch: true? Does it conflict with watchFiles? After all, if the file changes, the project will be rebuilt and the "dist" file will naturally change as well.
Similar to the first point, in my case, is it enough to set only one of devServer.static.watch and devServer.watchFiles?
The reason for setting hot: false is that without this line, the console would output the following:
```
[HMR] Waiting for update signal from WDS...   VM3367 log.js:24 
[HMR] Waiting for update signal from WDS...   VM3668 log.js:24
[HMR] Waiting for update signal from WDS...     log.js?7596:24
```
I don't have the HMR plugin installed, and I don't know why the default value for hot is not false, so would it be better for me to set it explicitly?

As was described in migration guide, you should use watchFiles, webpack don't know is this modules with hot or just copied file

static !== dist, webpack-dev-middleware handle webpack files, static is like public directory in your project and it is watched by default (because you can change favicon.ico/index.html when it was created manually and etc files)

watchFiles just watch files and reload browser when something was changed

As was described in migration guide, you should use watchFiles, webpack don't know is this modules with hot or just copied file

Okay.

static !== dist, webpack-dev-middleware handle webpack files, static is like public directory in your project and it is watched by default (because you can change favicon.ico/index.html when it was created manually and etc files)

This is a configuration inherited from v3. In the v3 version of the official website documentation example, the contentBase is set like this:

var path = require('path');

module.exports = {
  //...
  devServer: {
    contentBase: path.join(__dirname, 'dist'),
    compress: true,
    port: 9000
  }
};

So the previous setting of contentBase to dist should mimic the setting of the official example. The reason why it continues to be written this way in v4 is that the migration guide doesn't describe the changes to static options in detail (it doesn't even clarify the relationship between the old and new fields in the two versions), so it just renames contentBase to directory.

You can set dist as static, but it is unnecessary in most of cases, you have public part of your application, and it is static

@alexander-akait

@alexander-akait
Oh, I almost forgot to ask. We seem to have missed something.

The reason for setting hot: false is that without this line, the console would output the following:
[HMR] Waiting for update signal from WDS...   VM3367 log.js:24 
[HMR] Waiting for update signal from WDS...   VM3668 log.js:24
[HMR] Waiting for update signal from WDS...     log.js?7596:24

Do I need to set hot: false?

Can you provide example of the problem? I think you should not disable hot

@alexander-akait

@alexander-akait
You can take a look at this.

@alexander-akait

@alexander-akait PTAL🙏

@liby

@liby What is the problem, reload is working for you, hot will not because you don't have hot code for your application

@alexander-akait

@alexander-akait
Oh, I almost forgot to ask. We seem to have missed something.
The reason for setting hot: false is that without this line, the console would output the following:
[HMR] Waiting for update signal from WDS...   VM3367 log.js:24 
[HMR] Waiting for update signal from WDS...   VM3668 log.js:24
[HMR] Waiting for update signal from WDS...     log.js?7596:24
Do I need to set hot: false?

@alexander-akait The problem is that these descriptions.

If I do not set hot: false, I will see the following when I open the console:

[HMR] Waiting for update signal from WDS...   VM3367 log.js:24 
[HMR] Waiting for update signal from WDS...   VM3668 log.js:24
[HMR] Waiting for update signal from WDS...     log.js?7596:24

But obviously, I didn't explicitly turn on HMR in my configuration, there are no plugins installed. I also mentioned this problem at the beginning, as shown in the picture below.

I wonder why the console outputs this information, and I don't know if I want to set false to prohibit them from being output to the console.

I can't reproduce, please provide all steps, reload is working with hot: true and hot: false

I can't reproduce, please provide all steps, reload is working with hot: true and hot: false

open https://github.com/liby/Webpack_Demo
git clone git@github.com:liby/Webpack_Demo.git demo
cd demo
yarn
yarn start
open the console

@liby

@liby Expected, what is wrong?

hot is true by default, so output:

[HMR] Waiting for update signal from WDS...
[webpack-dev-server] Hot Module Replacement enabled.

liveReload is true by default, so output:

[webpack-dev-server] Live Reloading enabled.

Oh, then I'm not so confused now. Maybe you didn't notice the problem above at first, or you didn't understand what I mean. I’ll explicitly set them to false. That shouldn't be a problem, right?

I don't understand too, what is the problem, your example works as expected. Yes if you set hot: true and have files in builds, for example copy-webpack-plugin which are involved in build you need to use watchFiles, otherwise webpack doesn't know what do when you change this files hot reload or live reload. here is a suggestion to improve this work, if none of the modules received hmr update and hash was changed do live reload

I don't understand too, what is the problem, your example works as expected.

I just want to ask about the default value of hot, and now I've got the answer. It's on by default.

Yes if you set hot: true and have files in builds, for example copy-webpack-plugin which are involved in build you need to use watchFiles, otherwise webpack doesn't know what do when you change this files hot reload or live reload.

For some reason, I only intend to enable live reload in the project at present, and I have no idea of enabling hot reload for the time being.

here is a suggestion to improve this work, if none of the modules received hmr update and hash was changed do live reload

Thank you. Have a nice day.

For some reason, I only intend to enable live reload in the project at present, and I have no idea of enabling hot reload for the time being.

In your case just set hot: false

This may be out of scope for wds, but it'd be great to have multi/SSR compilers have first class support for HMR, similar to Vite.

Currently webpack-dev-server adds some additional entires for target: "node" and friends that ultimately do nothing (https://github.com/webpack/webpack-dev-server/blob/master/lib/Server.js#L273-L283).

Instead it would be awesome if we could support a non web implementation of https://github.com/webpack/webpack-dev-server/blob/master/client-src/index.js that would connect to the websocket, emit changes to webpack/hot/dev-server-only and ultimately enable HMR for the server automatically in isomorphic apps.

On top of this whenever the multi compiler is invalidated, you'd check to see if the file that was modified can be handled by the web compilers, and if so do an HMR there. If not then always reload the web compiler. The server compiler should always be able to HMR or exit.

This is probably worth it's own issue and I'm happy to create one if so.

@DylanPiercey

@DylanPiercey make sense, do you want to send a PR?

@alexander-akait

@alexander-akait Hi, I think this thread can be safely closed. The title of the problem has been resolved: if someone wants to have "live" reload, then just explicitly add the watchFiles so that webpack can know where to watch the changes. This part is very clearly documented in devServer.liveReload.

hot or not is a different story. Use React framework as an example, one will need to take a look at another plugin: https://github.com/pmmmwh/react-refresh-webpack-plugin.

Navigation Menu

Repository navigation

reload browser when hash is changed but no modules was updated #3794

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

reload browser when hash is changed but no modules was updated #3794

Description

Activity

alexander-akait commented on Sep 4, 2021

xavierfoucrier commented on Sep 4, 2021

liby commented on Sep 7, 2021

alexander-akait commented on Sep 7, 2021

alexander-akait commented on Sep 7, 2021

alexander-akait commented on Sep 7, 2021

liby commented on Sep 7, 2021

alexander-akait commented on Sep 7, 2021

liby commented on Sep 10, 2021

alexander-akait commented on Sep 10, 2021

liby commented on Sep 10, 2021

liby commented on Sep 12, 2021

alexander-akait commented on Sep 13, 2021

liby commented on Sep 13, 2021

alexander-akait commented on Sep 13, 2021

liby commented on Sep 13, 2021

alexander-akait commented on Sep 13, 2021

alexander-akait commented on Sep 13, 2021

liby commented on Sep 13, 2021

alexander-akait commented on Sep 13, 2021

liby commented on Sep 13, 2021

alexander-akait commented on Sep 13, 2021

DylanPiercey commented on Nov 1, 2021

alexander-akait commented on Nov 1, 2021

nyngwang commented on Feb 29, 2024

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions