-
Notifications
You must be signed in to change notification settings - Fork 10.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hot Module Reloading (HMR) Not Working #864
Comments
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 |
Yeah I've read that it should work by specifying that in the devServer configuration. That said, it won't work for some people based on my research, for me that isn't working either, I just tested it and same error. I'm going to continue digging into this. |
Mm... I've tried using |
For the moment, developing on |
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 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 Placing the headers object as is under assets instead solved the errors for me and also exposed me to the attack being discussed. Changing What I believe to be the secure solution to this is to run You can check for vulnerability by running |
It seems that webpack dev server is not recognizing 0.0.0.0 as localhost for hot module replacement. running:
seems to work though. Strange that this only happened to me with the bootstrap boilerplate, the default project creation seems to be working fine? |
The change only happened in the past few days (and on a dot release so we
inherited the breaking change without notice) so if you started a site
before then you won't see the problem.
…On Thu, Apr 27, 2017, 8:12 AM fpaboim ***@***.***> wrote:
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?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#864 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEVhwX0etsJ7D9JgMXjhMxfaNr_WsgSks5r0LBGgaJpZM4NJoBx>
.
|
Ah, right. webpack-dev-middleware passed If |
Decided it'd be simplest to just use 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. |
0.0.0.0 means "all IPs on the local machine". It doesn't actually represent a routable IP address - You're not supposed to hit 0.0.0.0 directly in your browser. |
@Daniel15 yeah, it was so the dev server would just work on local and remote hosts without having to explicitly set the IP but with the webpack change we had to drop that. |
@KyleAMathews - but the option to set the |
Yeah that's unchanged.
…On Mon, May 22, 2017, 12:02 PM g8t guy ***@***.***> wrote:
@KyleAMathews <https://github.com/kyleamathews> - but the option to set
host with --host will remain intact? We need it to specify where to send
the hot reloading requests and it is not always the localhost
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#864 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEVh10c8SKYS6S5kJ2fCG9377UF3O6eks5r8WtVgaJpZM4NJoBx>
.
|
I'm not certain the fix is better than the problem it solved. Sure, it works for |
@webOS101 if you run |
or you could just use browsersync.
…On May 22, 2017, 15:04 -0500, Michael Deeb ***@***.***>, wrote:
@webOS101 (https://github.com/webos101) if you run gatsby develop --host <your-machine>.local you will get all of that functionality back.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub (#864 (comment)), or mute the thread (https://github.com/notifications/unsubscribe-auth/AC_daV8P_vYwlEIbP9M-Af-8iHX2kwjoks5r8eo8gaJpZM4NJoBx).
|
Even though this issue is long closed, I was having the same problem with @fpaboim - Your suggestion works for me. |
Just wanted to add I also was having the same issue with HMR when accessing via the network. I found substituting --host xxx.xxx.xxx.xxx with the actual IP address of the server running Gatsby solved my problem. |
It seems like specifying the LAN IP of your development machine as 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 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. |
@michaek Would you be able to do this using Gatsby's custom webpack config hooks? |
@m-allanson Yes, it's possible (and I'm doing it), it just seems to involve too much knowledge about the configuration internals to be something I'd recommend:
I think it would be better for for most people if Gatsby accepted a separate configuration option for the public host where assets will be requested from, rather than assuming that's the same as the dev server hostname and port. |
how would I get hot-reloading working if I'm running |
@waspinator I launch gatsby from inside a container like this Then my solucion si puting the next code inside 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 |
@waspinator easiest way is to run the container with --net host. This will put the container on the host machines network. If the container is running on your local machine, you would be able to then connect to localhost:8000. If it is a remote system you have ssh access to, then use SSH to forward the port over a tunnel. With openssh-client it would look like this: ssh -L 8000:localhost:8000 userid@yourremoteserver Then on your local machine you can go to http://localhost:8000 and it will forward over the ssh tunnel to the container. |
Inspired by @crispamares, here is my working solution. The key change, other than refactoring for
exports.onCreateWebpackConfig = ({ getConfig, stage, actions }) => {
if (stage !== "develop") {
return;
}
if (typeof process.env.LANDO === 'undefined') {
return;
}
process.env.PUBLIC_HOST = 'docs.front.monin.lndo.site';
let config = getConfig();
if (typeof process.env.PUBLIC_HOST !== 'undefined' && typeof config.output !== 'undefined') {
config.output.publicPath = '';
config.entry.commons = config.entry.commons.map(point => {
if (/webpack-hot-middleware/.test(point)) {
point += '&dynamicPublicPath=true'
}
return point;
});
}
console.log({ output: config.output, entry: config.entry });
actions.setWebpackConfig({
output: config.output, entry: config.entry, devServer: config.devServer
});
} |
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. |
@bezoris - |
In my case I was operating within a docker container.
|
127... also refuses to connect. I think you're right though, something is tying up localhost.EDIT: Resolution (at least for me) A bit of process sniffing and Googling revealed that "irdmi" was stealing port 8000. I edited that in /etc/services and all is fine now. The "Intel Remote Desktop Management Interface" is a defunct hardware service from the 90's that listens on 8000... this may also explain why it's present on my old - but still kicking - Thinkpad x220 dev-box. Strangely, 8080 (set to http-alt for tcp/udp) still fails to connect. Ah well... a half-win then. Thanks @Daniel15, that sent me down the right track. Best, Chris. |
gatsby develop --host 0.0.0.0 --port 8000 works with me |
all praise |
Gatsby version: 0.12.46
Node version: 6.4.0
OS version: OSX El Capitan 10.11.6
Some hours ago I noticed that the hot module reloading (HMR) wasn't working, when I run
npm run develop
to start developing and make a change in my component, I get this error and warning in the chrome console:Error:
Warning:
I did some research and it seems that this issue has to do with
webpack-dev-server
as mentioned here.A webpack-dev-server/middleware security issue found some days ago, and I think the update breaks some configuration on various projects.
I found these disscussion in the webpack-dev-server github issues as well:
It's strange, yesterday I was working with HMR without any problems.
Is anyone facing the same issue?
The text was updated successfully, but these errors were encountered: