fix: use relative HMR path

[palerdot]

Construct webpack hmr path relative to the request origin path to prevent url construction issues when accessing from local ip or any other ip that may be mapped to the dev server.

This PR makes following changes to getHmrPath() method in packages/gatsby/src/utils/webpack.config.js

• Always use the relative path /
• Getting rid of manual url construction with protocol, hosts, ports etc as the relative path will automatically take care of this construction

[pieh]

Hey, could you list scenarios that you tested this and it works? We definitely need to verify any other scenarios to be as sure as possible that this won't break for some cases

[drubin]

@pieh This should work in all situations where you host Gatsby on the root of the domain/IP. If you do access it via a Nginx/proxy on a sub URL you will need to use the GATSBY_WEBPACK_PUBLICPATH which you would have to do anyway.

I think the previous implementation made a wrong assumption that the by using the same IP address that the webpack was bound to be the same as the public-facing URL (in most cases this would be the same but not always).

All this means is that the URL for hmr that is generated will not include the domain/port/proxy. Since this is requested from the page its self the borwser will infer where to fetch it from (i.e the same place the page came from which seems like the sanest default).

For example, if your dev ENV sites inside a docker image or behind an HTTP proxy (for ssl/name based routing).

is HMR used for anything other than the browser fetching it?

[pieh]

@drubin That is very logical and usually I would agree with you, but for some reason we had ip/port there as path even if docs for HMR doesn't use that in examples. I'm not sure if that is misconfiguration (using too specific path) or there was actual reason for that (one that I can't find in git history)

[drubin]

@pieh Yes, you are right I tried quickly searching back in the history

gatsby/packages/gatsby/src/utils/webpack.config.js

Line 92 in 3dbc3eb

`${require.resolve(`webpack-hot-middleware/client`)}?path=http://${program.host}:${webpackPort}/__webpack_hmr`,

I found it an older implementation

${require.resolve(`webpack-hot-middleware/client`)}?path=http://${program.host}:${webpackPort}/__webpack_hmr

Seems like it was loading from another plugin and that plugin was passing it in as a query param. That doesn't seem to be the case?

But of course without actually knowing why it was there in the first place its hard to figure out if it still passes that use case.

[pieh]

I tried searching known issues and didn't find any so I think changing to relative is worth trying - if there will be issue reported we can revert this

[KyleAMathews]

I don't remember why the code works as it does either. It's possible an earlier version of webpack/rhl needed things like this and then we didn't update.

[pieh]

Thanks @palerdot!

[drubin]

@palerdot thanks for the help fixing this.

btw I am not actually on the Gatsby project, I just happened to have the same problem you did. :)

[palerdot]

@pieh @drubin Thanks to you guys for the pointers you gave me. I was personally facing this issue as my gatsby server was inside my vagrant machine and I cannot access it from my host because of hmr url problems. Hopefully, this fix helps people with similar setup.

[palerdot]

@pieh @drubin @KyleAMathews Is info on GATSBY_WEBPACK_PUBLICPATH mentioned anywhere in the docs? I have not seen this environment variable anywhere in the docs. Maybe I didn't look well enough. It should be mentioned somewhere in the docs, so that people with different setup like vagrant or nginx reverse proxy should be able to get up and running without much sweat.

[KyleAMathews]

@thebigredgeek was there a reason you picked an ENV variable for the publicpath instead of a command flag? Running gatsby develop --publicpath /hi-folks/ seems better.