gatsby: Hot Module Reloading (HMR) Not Working

It seems that webpack dev server is not recognizing 0.0.0.0 as localhost for hot module replacement.

running:

gatsby develop --host localhost --port 8000

seems to work though. Strange that this only happened to me with the bootstrap boilerplate, the default project creation seems to be working fine?

For the moment, developing on 0.0.0.0:8000 instead of the localhost version fixes the issue.

@waspinator I launch gatsby from inside a container like this gatsby develop -H 0.0.0.0 and works fine. The problem comes when you want to access the web from other machine, like a mobile device.

Then my solucion si puting the next code inside gatsby-node.js

function modifyWebpackConfig(wp) {
	if (wp.stage == "develop") {
		let config = wp.config;
		console.log("OPEN THIS: ", "http://"+process.env.PUBLIC_HOST+':'+wp.program.port);
		if (process.env.PUBLIC_HOST) {
			config._config.output.publicPath = config._config.output.publicPath.replace('0.0.0.0', process.env.PUBLIC_HOST);
			config._config.entry.commons = config._config.entry.commons.map(point => {
				if (/webpack-hot-middleware/.test(point)) {
					point += '&dynamicPublicPath=true'
				}
				return point;
			})
		}
	}
}

module.exports = {modifyWebpackConfig}

The last thing is suppliying the PUBLIC_HOST env variable when you launch gatsby.develop

It seems like specifying the LAN IP of your development machine as --host does thread the needle of letting your dev server be accessible on the network, while generating assets that refer to its network-accessible URLs.

However, since the dev server is no longer listening for connections on 127.0.0.1, that breaks any local reverse proxy you may have set up. Perhaps you have resolution for projectname.yourmachine.test and a local reverse proxy for that virtual host from say, 80 -> 8001 , so your colleagues (or your device library) can test any work in progress without having to know the details of your network address and port configuration. If that’s the case, there’s not currently a way to make it work (without reverse proxying to your LAN address instead of localhost).

The current approach to defining the HMR entry point assumes that the dev server hostname and port will always be public-facing. I’d suggest that it may be better to optionally configure the URL from which webpack looks for its bundles separately from the host/port that the dev server is running on, as they’re not always the same.

Even though this issue is long closed, I was having the same problem with localhost when following part one of the tutorial.

@fpaboim - Your suggestion works for me.

gatsby develop --host 0.0.0.0 --port 8000 works with me

Decided it’d be simplest to just use localhost as the default host https://github.com/gatsbyjs/gatsby/commit/7cd0afb0365299022e464e300a21f344b3e8d2cd

The reason the default host was set to 0.0.0.0 in the past was so that Gatsby would work by default when developing on a remote server but that’s a small convenience that we can drop.

For the moment, developing on 0.0.0.0:8000 instead of the localhost version fixes the issue.

Thanks… I’m aware that this is a two-year old thread, but I just ran into the same issue. And switching to 0.0.0.0:8000 did indeed fix things. Strange.

how would I get hot-reloading working if I’m running gatsby develop from within a docker container?

Hey! I haven’t been up to date on the codebase in awhile, but a security vulnerability in a static site is such a rarity that I ended up catching up. Feel free to correct any of this if it’s off.

From what I can see, gatsby actually uses hapi and hapi-webpack-plugin in lieu of webpack-dev-server so disableHostCheck: true isn’t valid anywhere in develop.js

Looking at Usage 1), and gatsby’s develop.js, I believe the headers object actually isn’t doing anything right now. webpack-hot-middleware has minimal documentation, but doesn’t mention headers and webpack-dev-middleware does and webpack-dev-server links to a webpack-dev-middleware release with a security fix related to Access-Control-Allow-Origin.

Placing the headers object as is under assets instead solved the errors for me and also exposed me to the attack being discussed. Changing * to localhost, localhost:8000, or http://localhost did not work, but http://localhost:8000 worked as expected. That said, everything still worked on 0.0.0.0:8000, which leads me to believe this solution is still vulnerable.

What I believe to be the secure solution to this is to run gatsby develop --host domain.local (or LAN IP) --port #### as the site then becomes unavailable over 0.0.0.0. Other options include exposing the header with a user config, and/or to just warn people of the risk when running gatsby develop without the host argument. A DNS rebinding attack will always be possible as long as the server is listening on anything routed to localhost (localhost, 0.0.0.0, 127.0.0.1).

You can check for vulnerability by running gatsby develop -p 3000 (the demo site expects port 3000), opening the browser web inspector, and going to dnsrebinder.net (leaving unlinked intentionally). Eventually you’ll see a not_found come back with a 404 from your development server. The vulnerability is fixed if there is no status code associated with the request.

Gahhh that explains it. There’s been several people complaining about this and I couldn’t figure out why. Thanks for the research!

So I think we just need to change https://github.com/gatsbyjs/gatsby/blob/master/lib/utils/develop.js#L167 to headers: { "Access-Control-Allow-Origin": "localhost:8000" }.