HMR ignores public/publicPath/sockHost/sockPort/sockPath configs

[maxlk]

• Operating System: macOS 10.14.5

• Node Version: 12.4.0

• NPM Version: 6.9.0

• webpack Version: 4.38.0

• webpack-dev-server Version: 3.7.2

• Browser: Google Chrome 75.0.3770.100

• This is a bug

• This is a modification request

Code

Repository with repro: https://github.com/maxlk/webpack-hmr-behind-proxy-issue/

// webpack.config.js
//...
    devServer: {
      hot: true,
      public: "localhost:8080",
      sockHost: "localhost",
      sockPort: 8080,
      disableHostCheck: true
    }
//...

A website is served by 3rd party HTTP server. For example it's served from origin http://local.myhost.com.

JavaScript bundle is served by WDS and is loaded loaded from different origin, for example http://localhost:8080.

Expected Behavior

HMR should load updates from WDS URL. It is provided in public and publicPath config options. It's also available in sockHost, sockPort and sockPath config options.

Update's URL should be like http://localhost:8080/5cc71fea9aecb707e3fc.hot-update.json.

Actual Behavior

HMR tries to load update from window.location (even with pathname(?!)) instead of building the correct URL from config (<public><publicPath><update-hash>.hot-update.json or <sockHost>:<sockPort>/<sockPath>/<update-hash>.hot-update.json).

Particularly in this example it tries to load update from http://local.myhost.com/some/path/5cc71fea9aecb707e3fc.hot-update.json.

It causes 404 error, hot reload fails and full reload is triggered.

For Bugs; How can we reproduce the behavior?

• git clone git@github.com:maxlk/webpack-hmr-behind-proxy-issue.git
• cd webpack-hmr-behind-proxy-issue
• npm install
• npm start
• Open http://localhost:9876/www/ in web browser.
• Open DevTools and make sure that Preserve log is enabled in Console and Network.
• Make any change in src/print.js and save it.
• You will get GET http://localhost:9876/www/5cc71fea9aecb707e3fc.hot-update.json 404 (Not Found) error and full reload (instead of hot reload) will be triggered.

[alexander-akait]

Why you use public instead host and port options?

[maxlk]

@evilebottnawi
I'm not using them instead, I'm using them together:

1. Default values of host ('localhost') and port (8080) suit me, so there is no reason to override them.
2. According to documentation this is the purpose of public config:

...the inline client script does not always know where to connect to. It will try to guess the URL of the server based on window.location, but if that fails you'll need to use this.

It's exactly my case - in inline mode HMR guess URL from window.location, but it fails. So, I specify the correct URL in public, but HMR ignores it and fails anyway.

BTW I tried to explicitly specify host and port (both: same as default values and different values) - the problem still exists.
And HMR also ignores publicPath option. So, I updated the issue description.

[maxlk]

I debugged it a bit and that what I found:

• Path to update manifest is built in this line: https://github.com/webpack/webpack/blob/8a7597aa6eb2eef66a8f9db3a0c49bcb96022a94/lib/webworker/WebWorkerMainTemplate.runtime.js#L27
• $require$.p from this line is a output.publicPath webpack option, not devServer.publicPath and definitely not ${devServer.public}/${devServer.publicPath}.

It seems like having two different options with the same name publicPath led to confusing between them (this time not in usage but in implementation).

[dcecile]

I think this is probably fixed in webpack-dev-server by #1858.

But the reference to window.location might be coming from an entirely different location: https://github.com/facebook/create-react-app/blob/master/packages/react-dev-utils/webpackHotDevClient.js

Check for the comment at the top of the file:

This alternative WebpackDevServer combines the functionality of...

See facebook/create-react-app#3814 for the rejected create-react-app issue.

[qraynaud]

I have the same issue with webpack-dev-server 3.9.0. I have a proxy that redirects requests to WDS but it does not support proxying websockets. So I thought I could just change the sockHost & sockPort options to get the socket loaded directly from WDS. This is not working at all sadly…

[alexander-akait]

@qraynaud please create reproducible test repo, thanks

[stefanbuck]

Hi, I'm facing the same issue with the latest webpack and webpack-dev-server version. I just raised a PR to update webpack in the test repo that @maxlk created and it seems like #1858 did not fixed the issue.

maxlk/webpack-hmr-behind-proxy-issue#1

[stefanbuck]

Not sure how useful this information is, but hard coding __webpack_require__.p = 'http://localhost:8080/' or __webpack_public_path__ = 'http://localhost:8080/ in webpack-hmr-behind-proxy-issue/blob/master/src/index.js makes the thing function correctly.

[bebraw]

I found out that it's possible to work around this issue by:

1. Using devServer.proxy configuration against the other server. This means you'll access it through the webpack server.
2. Setting output.publicPath to / so all queries will be performed against the root since that's where the HMR client will look into.

Here's a sample of 1.:

proxy: {
    '*': { target: 'https://127.0.0.1:8000', secure: false },
},

[alexander-akait]

We do big refactor in webpack-dev-server v4, now you have client.webSocketURL option, where you can URL to web socket server, also now you can change path and not only using webSocketServer: { type: 'ws', options: { path: '/custom-path' } }.

NOTE, client.webSocketURL only affect on URL to web socket server, it is not change path/port/host of web socket server itself. Before we have mixed logic so we have these problem, now logic is separated, i.e. you can change path/port/host of web socket server and you can change path/port/host of web socket URL to server (useful when you proxy dev server).

Anyway if you will faced with the issue again, feel free to open new issue, sorry for delay

[r4j4h]

Hope this gets released soon in a beta version so more people can easily try it out

[snitin315]

@r4j4h we have plan to do rc release by next week.

[r4j4h]

@snitin315 that's great to hear! thank you for giving me a timeline 🎉

I also have a wonder that I haven't seen mentioned, does sockjs_url: '/__webpack_dev_server__/sockjs.bundle.js', need to respect client.webSocketURL as well? Or have its own setting?

Even if not, since it's under folder webpack_dev_server in worst case I imagine another proxy mapping could be made.

But if I understand correctly, something would have to be done in a reverse proxy'd by path scenario, or else those calls will not find their way to the webpack dev server in those cases.

[r4j4h]

Just wanted to report in the quickest way instead of creating a new issue, that after updating to the new version things largely work, much better than before, but there seems to still be a problem around some hot reloading after a file changes:

[webpack-dev-server] App updated. Recompiling...
vendors.bundle82e9.js:220190 [webpack-dev-server] App hot update...
jsonp chunk loading:500 GET https://ambassador.local.dev/main.9846f7952cdcd5668120.hot-update.json net::ERR_ABORTED 404 (Not Found)
__webpack_require__.hmrM @ main.bundlec8c3.js:64402
hotCheck @ main.bundlec8c3.js:63670
check @ vendors.bundle82e9.js:221053
(anonymous) @ vendors.bundle82e9.js:221094
emit @ vendors.bundle82e9.js:66668
reloadApp @ vendors.bundle82e9.js:220974
ok @ vendors.bundle82e9.js:216918
(anonymous) @ vendors.bundle82e9.js:220723
client.onmessage @ vendors.bundle82e9.js:216732
Navigated to https://ambassador.local.dev/patient-chart/v1/patients/1/cases/1

A file named as such main.d63f158299166e8b11e2.hot-update.json was attempted to be loaded from root instead of the public path, and upon 404 it reloaded the whole page.