V3.3.0 live reload broken when set hostname to 0.0.0.0:xxxx

[njugray]

• Operating System: MacOS

• Node Version: v10.15.0

• NPM Version: 6.4.`

• webpack Version: 4.29.6

• webpack-dev-server Version: 3.3.0

• This is a bug

• This is a modification request

Code

webpack-dev-server/client-src/default/index.js

Line 210 in 99e8db0

port = self.location.port;

When start a node server like 0.0.0.0:8080, and load resources from 0.0.0.0:9000, Port was reset to self.location.port , which actually is 8080.

For Bugs; How can we reproduce the behavior?

• Start webpack-dev-server and listen at e.g. 0.0.0.0:9000
• Load resources from another local server like: 0.0.0.0:8080

Expected Behavior

Live reload should listen 0.0.0.0:9000

Actual Behavior

Live reload listen 0.0.0.0:8080

[alexander-akait]

@njugray Please create minimum reproducible test repo

[njugray]

@evilebottnawi

here: https://github.com/njugray/webpack-live-reload

[njugray]

1. Install dependencies and npm run dev

2. Visit: http://127.0.0.1:8080/

3. See network inspect, will get:
   

[alexander-akait]

Thanks!

[alexander-akait]

/cc @hiroppy can you investigate? Don't have time on this right now 😞

[ryank311]

This one also affects us because we run the dev server on a different port than our node server that is serving the page. It would be huge for us if the sockjs host was configurable/override-able, as it would let us do things like run the webpack-dev-server on a different host or in a container separate from our node server.

[alexander-akait]

Maybe sockHost and sockPort? Now we already support sockPath

[ryank311]

Yeah, I took a look and if we could set the sockHost and sockPort, that would work for us. Unfortunately with just sockpath, it doesn't give us enough control over the domain. Another alternative would be to utilize the publicPath, publicHost and publicPort that are already part of the config, but either would unblock us from upgrading.

Also, we should probably document the sockHost, sockPort and sockPath as I was only able to reason about them by stepping through the code.

[alexander-akait]

sockPort PR #1792, yep we will documented this in near future

[alexander-akait]

/cc @hiroppy i think we do breaking change here 2f7f052 😞

[ryank311]

I did see the PR and it looks like it would resolve my issue. Is there a reason why this is different from the public host and Port? Afaik there wouldn't be a scenario when those would be different.

[alexander-akait]

I think it is bug, and should be by default with public host and public port, previously main commiter don't add tests on many features and now we have many weird code and sometimes break something, now we increase tests and in future this problem will be less, sorry

[alexander-akait]

Any way PR welcome

[knagaitsev]

@ryank311 sockHost and sockPort would be different from host and port in the case mentioned here where the Dev Server is behind a proxy. The inferring of the port from location.port in that PR is the breaking change here, so it would be beneficial to have options to set it rather than to try and guess the socket host and port.

[zhangyuang]

my pr can fix your problem
and you can also start your app by webpack-dev-server --port 8080 make it get the true port.
because it use location.port if your urlParts.port is undefined
but at this time ,you can't add sockPath in your option,
because here
if my pr is merge, you can set sockPort by webpack-dev-server --sockPort 8080

[knagaitsev]

@zhangyuang yes that will fix the immediate issue here. 2 other things that probably need to be done:

• revert parts of this so it is not default behavior to infer the port from location.port (it will be possible to achieve this behavior manually when sockPort is added)
• add sockHost so that the dev server can exist on a different host

[zhangyuang]

@zhangyuang yes that will fix the immediate issue here. 2 other things that probably need to be done:

• revert parts of this so it is not default behavior to infer the port from location.port (it will be possible to achieve this behavior manually when sockPort is added)
• add sockHost so that the dev server can exist on a different host

you can use host option to use correct host now

[alexander-akait]

@zhangyuang

revert parts of this so it is not default behavior to infer the port from location.port (it will be possible to achieve this behavior manually when sockPort is added)

Can you send a PR?

add sockHost so that the dev server can exist on a different host

Already done

[zhangyuang]

@zhangyuang

revert parts of this so it is not default behavior to infer the port from location.port (it will be possible to achieve this behavior manually when sockPort is added)

Can you send a PR?

add sockHost so that the dev server can exist on a different host

Already done

ok

[zhangyuang]

@zhangyuang

revert parts of this so it is not default behavior to infer the port from location.port (it will be possible to achieve this behavior manually when sockPort is added)

Can you send a PR?

add sockHost so that the dev server can exist on a different host

Already done

already finish,now if you add sockPort, it will be never use location.port
but as I said before，if you add sockPort but don't add sockPath
the hostname expression result is error
i hope you can refactoring previous behavior in the future

[alexander-akait]

@zhangyuang please revert this, and let's do this in other PR, it is male dirty history and dirty changelog

[alexander-akait]

/cc @hiroppy i think we need revert 2f7f052, what do you think?

[hiroppy]

@evilebottnawi Yeah, could you revert only client-src/default/index.js because puppeteer is already used?

[alexander-akait]

@hiroppy yep, some busy in this week, feel free to do this

[iiroj]

It seems this has been fixed in 58d1682#diff-bd664d218d585ff7bd6ceced46bd877aL229, now we're just waiting for a new release.

[knagaitsev]

add sockHost so that the dev server can exist on a different host

Already done

@evilebottnawi Where is sockHost? I can't find it in the options, and can't find anything suggesting that it has been implemented.

[alexander-akait]

@Loonride hm no docs?

[knagaitsev]

@evilebottnawi Yes but also sockHost just does not exist here: https://github.com/webpack/webpack-dev-server/blob/master/lib/options.json. Unless it exists under another name, I don't think it has been implemented

[alexander-akait]

Yes, it is bug, but it is options only for CLI, you can use this in webpack.config.js

[jonaldinger]

@evilebottnawi I'm also not understanding how sockHost can be set. sockPort was implemented in PR #1792, but the string "sockHost" does not currently exist anywhere in the master branch of the source code of this repo.

Assuming that /client-src/default/index.js is where the actual socket is being created (via socket(socketUrl, onSocketMsg);), it looks like the hostname portion of the socketUrl is being derived from urlParts, which is derived from either

url.parse(__resourceQuery.substr(1));

or

getCurrentScriptSource();

with no method to override the hostname or infer from other config options. I'm not familiar with the inner workings of this project so it's possible I'm looking in the wrong place, or that the sockHost value could be coming in via __resourceQuery, or that I'm just completely overlooking something. But I'm interested in this feature so thought I would share my observations.

[alexander-akait]

Oh, yes we don't have sockHost now, i mean sockPath, if somebody needed in sockHost you can send a PR, it is easy

[pedrofurtado]

@hiroppy In what version this hotfix will be available? 👍

[hiroppy]

@pedrofurtado This fix will be fixed in the next version and the next version will be released in this week.

[pedrofurtado]

@hiroppy Thanks for feedback! 🤝

[ranand]

hi @hiroppy - thanks for all the awesome work in maintaining this. any chance that a fix (new release) will be available this week, please?

[alexander-akait]

Yes, release will be on this week

[Krzysiek555]

[Vue.js] FYI @vue/cli-service in version 3.7.0 uses webpack-dev-server in version 3.3.x
To benefit from the merged PR you will have to bump @vue/cli-service to 3.8.4 which has the webpack-dev-server in 3.4.1 Cheers!