Gatsby: Hot Reloading Not Working

[AGreenObject]

* Summary*
After developing my first hello-world using gatsby develop and viewing localhost:8000, I noticed that hot reloading isn't actually working for me. Changes made in VCS code are not being seen in browser, even upon reload of the page.

The only way to see changes I've made in VCS code to index.js is to restart my CLI and re-run gatsby develop

Steps I took
Command line:
gatsby new hello-world https://github.com/gatsbyjs/gatsby-starter-hello-world#v2
cd hello-world
gatsby develop (however, after this step, I get:

info ℹ ｢wdm｣: Compiled successfully. )

The terminal then hangs.

changed content in src/pages/index.js using VCS code.

Environment (if relevant)

System:
OS: Linux 4.4 Ubuntu 18.04.1 LTS (Bionic Beaver)
CPU: (12) x64 Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
Shell: 4.4.19 - /bin/bash
Binaries:
Node: 12.1.0 - /home/linuxbrew/.linuxbrew/bin/node
npm: 6.9.0 - /home/linuxbrew/.linuxbrew/bin/npm
npmPackages:
gatsby: ^2.4.2 => 2.4.2
npmGlobalPackages:
gatsby-cli: 2.5.12

File contents (if changed)

[LekoArts]

I can't reproduce this on my machine, please try Node v10 or v11 👍

[AGreenObject]

@LekoArts I've tried running the same procedure with both Node v10 and v11 with the exact same result. Is there anything else I should try or do you need more information about something?

[LekoArts]

Can you try another operating system or code editor? We'd need to find some sort of reproduction or information on how to reproduce this issue :O

[sidharthachatterjee]

@AGreenObject Could you inspect the console in your browser and check if the web socket calls (that enable HMR) are being completed?

Perhaps this has to do with web sockets being blocked in your network stack or something?

[rori4]

I can confirm I have the same issue. When I change the title in the gatsby config, the title just disappears. I have to redeploy the project in order for it to run properly and apply the change

[wardpeet]

@rori4 we sadly don't do HMR for gatsby-node, gatsby-config or gatsby-browser. You'll need to rerun gatsby develop or gatsby build

[AGreenObject]

@AGreenObject Could you inspect the console in your browser and check if the web socket calls (that enable HMR) are being completed?

Perhaps this has to do with web sockets being blocked in your network stack or something?

@sidharthachatterjee I'll check this out when I get home this evening.

[AGreenObject]

@sidharthachatterjee looks like the web socket isn't being blocked.

[AGreenObject]

Can you try another operating system or code editor? We'd need to find some sort of reproduction or information on how to reproduce this issue :O

@LekoArts I've tried another operating system, Windows 10 Home, 10.0.0.17763 Build 17763, using powershell--and I've gotten hot reloading to work. I'm not exactly sure what the issue is/was, but I can tell you that I was using Ubuntu on the WSL (Windows Subsystem for Linux), and I assume the issue that I was having must have something to do with this.

[wardpeet]

can you see if anything is being emitted through the websocket by watching eventstream. Could you also try to update fs.inotify.max_user_watches might be a silent error on your end.

[interglobalmedia]

Hi, I am having problems with hot reloading as well. Have been on and off, but today was really bad. I updated all my gatsby related plugins in case if there were some straggling version 1 or border version 2 straggling there (started with the gatsby default starter which I downloaded from the repo), and this is what I am working with now:

System:
    OS: macOS 10.14.4
    CPU: (8) x64 Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 11.14.0 - ~/.nvm/versions/node/v11.14.0/bin/node
    npm: 6.7.0 - ~/.nvm/versions/node/v11.14.0/bin/npm
  Languages:
    Python: 2.7.15 - /usr/local/bin/python
  Browsers:
    Chrome: 75.0.3770.90
  npmPackages:
    gatsby: ^2.9.4 => 2.9.4
    gatsby-image: ^2.1.4 => 2.1.4
    gatsby-plugin-emotion: ^4.0.7 => 4.0.7
    gatsby-plugin-feed: ^2.2.3 => 2.2.3
    gatsby-plugin-google-analytics: ^2.0.21 => 2.0.21
    gatsby-plugin-manifest: ^2.1.1 => 2.1.1
    gatsby-plugin-offline: ^2.1.3 => 2.1.3
    gatsby-plugin-react-helmet: ^3.0.12 => 3.0.12
    gatsby-plugin-sass: ^2.0.11 => 2.0.11
    gatsby-plugin-sharp: ^2.1.5 => 2.1.5
    gatsby-plugin-sitemap: ^2.1.0 => 2.1.0
    gatsby-plugin-typography: ^2.2.13 => 2.2.13
    gatsby-remark-copy-linked-files: ^2.0.13 => 2.0.13
    gatsby-remark-images: ^3.0.16 => 3.0.16
    gatsby-remark-prismjs: ^3.2.11 => 3.2.11
    gatsby-remark-responsive-iframe: ^2.1.1 => 2.1.1
    gatsby-remark-smartypants: ^2.0.9 => 2.0.9
    gatsby-source-filesystem: ^2.0.39 => 2.0.39
    gatsby-transformer-remark: ^2.4.0 => 2.4.0
    gatsby-transformer-sharp: ^2.1.21 => 2.1.21
  npmGlobalPackages:
    gatsby-cli: 2.5.8

Strangely, I also have been getting the following re Workbox in the Chrome DevTools Console:

workbox Router is responding to: /
11:16:59.596 workbox-core.dev.js:132 workbox Router is responding to: /component---src-pages-index-js-de75db7165a8435fa31c.js
11:16:59.600 workbox-core.dev.js:132 workbox Router is responding to: /page-data/index/page-data.json
11:16:59.605 workbox-core.dev.js:132 workbox Precaching is responding to: /webpack-runtime-0029c4e5aca2701ef598.js
11:16:59.610 workbox-core.dev.js:132 workbox Precaching is responding to: /app-c3c9e9507e5f82f92060.js
11:16:59.615 workbox-core.dev.js:132 workbox Using NetworkFirst to respond to '/page-data/index/page-data.json'
11:16:59.619 workbox-core.dev.js:132 workbox Precaching is responding to: /styles-fe3bab18b4dc88fb4d66.js
11:16:59.626 workbox-core.dev.js:132 workbox Precaching is responding to: /1-79a8ef40e04afc78e98d.js
11:16:59.632 workbox-core.dev.js:132 workbox Using CacheFirst to respond to '/component---src-pages-index-js-de75db7165a8435fa31c.js'
11:16:59.664 workbox-core.dev.js:132 workbox Router is responding to: https://www.google-analytics.com/analytics.js
11:16:59.673 workbox-core.dev.js:132 workbox Using StaleWhileRevalidate to respond to 'https://www.google-analytics.com/analytics.js'
11:17:00.092 workbox-core.dev.js:132 workbox Precaching is responding to: /manifest.webmanifest

Is that supposed to be happening?

I do not use the global install of gatsby because when I tried a while back there were a whole bunch of dependencies which were required and not added to the global install, AND hot reload did not work. So I switched to npx instead. Which was working well (with a hiccup or two on occasion but well overall) until yesterday. Here is the link to the repo for viewing: docscorneronline

Update: Now I am getting the following in the Chrome DevTools Console:

workbox-core.dev.js:132 workbox Network request for '/2b40ccbe4a28bd46ac66.hot-update.json' threw an error. TypeError: Failed to fetch
_print @ workbox-core.dev.js:132
(anonymous) @ workbox-core.dev.js:149
(anonymous) @ workbox-core.dev.js:1407
step @ workbox-core.dev.js:14
(anonymous) @ workbox-core.dev.js:27
Promise.then (async)
step @ workbox-core.dev.js:24
(anonymous) @ workbox-core.dev.js:25
Promise.then (async)
step @ workbox-core.dev.js:24
(anonymous) @ workbox-core.dev.js:32
(anonymous) @ workbox-core.dev.js:11
wrappedFetch @ workbox-core.dev.js:1424
(anonymous) @ workbox-strategies.dev.js:1035
step @ workbox-core.dev.js:14
(anonymous) @ workbox-core.dev.js:32
(anonymous) @ workbox-core.dev.js:11
_getFromNetwork @ workbox-strategies.dev.js:1061
(anonymous) @ workbox-strategies.dev.js:979
step @ workbox-core.dev.js:14
(anonymous) @ workbox-core.dev.js:32
(anonymous) @ workbox-core.dev.js:11
makeRequest @ workbox-strategies.dev.js:1020
(anonymous) @ workbox-strategies.dev.js:938
step @ workbox-core.dev.js:14
(anonymous) @ workbox-core.dev.js:32
(anonymous) @ workbox-core.dev.js:11
handle @ workbox-strategies.dev.js:942
handleRequest @ workbox-routing.dev.js:365
(anonymous) @ workbox-routing.dev.js:835
12:06:50.630 sw.js:1 Uncaught (in promise) TypeError: Failed to fetch

[interglobalmedia]

Now, when I went into another gatsbyjs v2 project which has been successfully deployed (very recently) after updating OSX (now on version 10.14.5), I am getting the following error in the console which usually goes away on refresh, but now does NOT:

Unhandled Rejection (SyntaxError): Unexpected token < in JSON at position 0
XMLHttpRequest.request.onreadystatechange
/Users/mariacam/Development/interglobalmedia/webpack/bootstrap:52
  49 | } else {
  50 |  // success
  51 |  try {
> 52 |      var update = JSON.parse(request.responseText);
  53 |  } catch (e) {
  54 |      reject(e);
  55 |      return;

And in the terminal console, I am getting the following:

info ℹ ｢wdm｣:
info ℹ ｢wdm｣: Compiled successfully.
Page not found /dev-404-page
Page not found /dev-404-page
Page not found /dev-404-page
Page not found /dev-404-page
Page not found /dev-404-page
Page not found /dev-404-page
Page not found /dev-404-page

[interglobalmedia]

FYI: I found out in my case that it was a Chrome browser issue. Gatsby works in Firefox and Safari for me but not Chrome. Hope this helps others who might be having similar issues.

[ken-nah]

I am also experiencing the same issue. Running on ubuntu 19.04

[wardpeet]

Mind sharing your environment by running gatsby info --clipboard in your project directory and paste the output here.

It would also be really helpful if you can create a reproduction or share your source code.

[gatsbot[bot]]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contributefor more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[franklinfarahani]

I had the same problem where only parts of my project were hot reloading. No error messages or warnings either. It turns out it was because the casing of the component name in my imports was not the same as the actual component folder name.

[lbittner-pdftron]

I'm having hot reload issues with certain parts of my project as well. When i make a change to the file i get the [HMR] bundle rebuilt in Xms message, but the content on the page does not actually change right away. I have found, however, that if I wait multiple minutes, the page will eventually update.

Running on MacOS 10.14.5.

[savkevip]

I have issue to with HR :/

[mtdenton]

I ran into this issue, it was solved by creating the project in the WSL2 file structure instead of the Windows file structure.

Original project that couldn't hot reload was created in C:Usersusername\Documents

Project that was able to utilize hot reloading was created in \wsl$\Ubuntu\homeusername (it's all under a "network device" apparently)

Quick tip for this also, you can open file explorer to your current WSL2 directory by running the command "explorer.exe .". It can also be accessed easily in VS Code by installing the VS Code Remote Development plugin, found here: https://code.visualstudio.com/docs/remote/remote-overview

[gatsbot[bot]]

Hey again!

It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.

Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY. Please feel free to reopen this issue or create a new one if you need anything else.

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks again for being part of the Gatsby community!

[RLloyd]

npm run develop -o

[gkatzioras]

I ran into this issue, it was solved by creating the project in the WSL2 file structure instead of the Windows file structure.

Original project that couldn't hot reload was created in C:Usersusername\Documents

Project that was able to utilize hot reloading was created in \wsl$\Ubuntu\homeusername (it's all under a "network device" apparently)

Quick tip for this also, you can open file explorer to your current WSL2 directory by running the command "explorer.exe .". It can also be accessed easily in VS Code by installing the VS Code Remote Development plugin, found here: https://code.visualstudio.com/docs/remote/remote-overview

@mtdenton's advice worked for me to enable HML, but I also had to run "code ." inside my WSL project folder. [dont forget the dot "." at the end!]

[NateRadebaugh]

For what it's worth, I was hitting this issue myself using a new gatsby-theme-blog starter project and resolved the issue by updating my dependencies. The starter repo had out of date dependencies when it was cloned/installed, so updating the version had the fixes I needed!

[keith-E]

I ran into this issue, it was solved by creating the project in the WSL2 file structure instead of the Windows file structure.

Original project that couldn't hot reload was created in C:Usersusername\Documents

Project that was able to utilize hot reloading was created in \wsl$\Ubuntu\homeusername (it's all under a "network device" apparently)

Quick tip for this also, you can open file explorer to your current WSL2 directory by running the command "explorer.exe .". It can also be accessed easily in VS Code by installing the VS Code Remote Development plugin, found here: https://code.visualstudio.com/docs/remote/remote-overview

This worked for me also, thanks! The WSL2 terminal was mounting directly to my Windows 10 user folder by default, so I created my Gatsby project there. After recreating my gatsby project (gatsby new projectname) in the WSL2/Linux file structure, hot reloading worked.

Also, a huge bonus in my case was that my compilation times (after performing a gatsby develop) went down from ~30000ms to ~3500ms.

[fullspectrumprocessing]

Are there any solutions for this issue on Mac?? Having the same problem with some of the components not hot reloading. Have to restart the whole server just to get updates.

[Tenkir]

Hot Reloading doesnt seem to work if I nest a component in a subdirectory inside src/components. For example, src/components/header.js reloads fine, while src/components/header/index.js does not.

Update:

This only happens if we do an implicit import.

_Does not work:_
src/components/header/index.js
import Header from './header

_Works as expected:_
src/components/header/index.js
import Header from './header/header

[fpigeonjr]

I ran into this issue, it was solved by creating the project in the WSL2 file structure instead of the Windows file structure.

Original project that couldn't hot reload was created in C:Usersusername\Documents

Project that was able to utilize hot reloading was created in \wsl$\Ubuntu\homeusername (it's all under a "network device" apparently)

Quick tip for this also, you can open file explorer to your current WSL2 directory by running the command "explorer.exe .". It can also be accessed easily in VS Code by installing the VS Code Remote Development plugin, found here: https://code.visualstudio.com/docs/remote/remote-overview

I can confirm that running on the WSL side does fix hot-reloading and the performance is a lot better. My CPU was running hot on the windows side so now this is the only way to live.

[facultymatt]

I see a behavior similar to @Tenkir but with case sensitivity.

filename: src/components/Header/index.js
does not work: import Header from './header/
does work: import Header from './Header/

[gixxerblade]

I ran into this issue, it was solved by creating the project in the WSL2 file structure instead of the Windows file structure.

Original project that couldn't hot reload was created in C:Usersusername\Documents

Project that was able to utilize hot reloading was created in \wsl$\Ubuntu\homeusername (it's all under a "network device" apparently)

Quick tip for this also, you can open file explorer to your current WSL2 directory by running the command "explorer.exe .". It can also be accessed easily in VS Code by installing the VS Code Remote Development plugin, found here: https://code.visualstudio.com/docs/remote/remote-overview

Amazing! It worked! Thank you

[wardpeet]

This might be a HMR bug and not a gastby bug. Is it possible to create a new bug with all the information you can put in.

Does this only happen on windows?

[ethernal]

I have same behavior with Chrome (Windows). Enterprise settings in Chrome, some content is blocked etc. please check Firefox if it is unlocked. Had similar issue with Cypress also due to Chrome policy.

[AAverin]

I also have issues with hot reload.
Difficult to tell when it started exactly, in gatsby develop when I save whole page reloads, indeed, but I kind of expect only one component to update on screen without whole page updating. Am I right to expect that?

Anyways, I also have aliases set up via gatsby-plugin-alias-imports. Others mention some import-related issues, so could be related to this also.

[wispyco]

Well not sure if this will help everyone, but I had setup WSL 2 through the insiders program, and when I downgraded my ubuntu version to wsl1 hot reload started working again. The command I had to run was wsl --set-version Ubuntu 1 more info here about WSL 2 https://docs.microsoft.com/en-us/windows/wsl/wsl2-install

[Nurou]

Having the exact same issue @Tenkir

[seandearnaley]

pulling my hair over WSL 2 hot reloading, doesn't seem to be detecting changes even though I'm in the linux file structure and webpack hmr seems to be working in the browser... it's like it's not seeing changes when I save then because gatsby develop log shows nothing.

UPDATE 1/5/2020: got this working: so apparently there was some confusion about these posts regarding the linux file system, I was creating my project in the ubuntu terminal under /mnt/c/Users/seand , thinking this was the linux file system, but actually it seems that is some kind of virtualized service.... if I go to /home, and create a project my personal folder, it works great.... I guess it's the difference between windows file system and linux file system and it's new to WSL 2. The performance difference is dramatic also.

[emthorne]

I had this same issue but solved it by updating my dependencies.
For reference: https://flaviocopes.com/update-npm-dependencies/

npm install -g npm-check-updates
ncu -u
npm update

This fixed it for me. Hope it helps.

[mfrench71]

npm update fixed this for me on Mac.

[KPS-GitHub]

Just in case it helps anyone like me, the fix for my little project was to run a 'gatsby build' before running 'gatsby develop'. No idea why this fixed my hot reload, but it's the only thing that's worked for me after a couple days of searching forums and trying a million different solutions.

[ryancwalsh]

I'm on a Windows 10 PC running a Laravel Homestead Vagrant Ubuntu VM, where I've been installing the Gatsby tutorial.

Unfortunately hot reloading has never worked yet.

After changing any code at all, I always need to completely stop and rerun gatsby develop --host=0.0.0.0.

My system already says:

cat /proc/sys/fs/inotify/max_user_watches
524288

so https://github.com/gatsbyjs/gatsby/issues/13918#issuecomment-500709995 didn't help.

npm update didn't help because of https://github.com/gatsbyjs/gatsby/issues/6834#issuecomment-619195994

And running gatsby build before running gatsby develop didn't help.

yarn add react-dom@npm:@hot-loader/react-dom didn't help.

Any other ideas? Thanks.

[ryancwalsh]

Hot reloading seems to work if I open PowerShell as Admin and run gatsby develop. I guess I'll just try to use Homestead Vagrant for the Laravel PHP / MySQL parts and then Windows for developing the Gatsby layer.

[aaronadamsCA]

The lack of support for hot reloading on WSL2 is a known issue that should eventually be resolved:

https://github.com/microsoft/WSL/issues/4739

TLDR, Windows file system changes are not reported to Linux, therefore hot reloading cannot do its thing.

[fmaiabatista]

WSL 1
cmd ver gives Windows build 10.0.18363.836
PowerShell wsl -l -v gives error which means it's v1 according to this.

Tried the following without success...

• localhost
• 127.0.0.1
• Files in Windows filesystem (C:Usersuser\Projectsproject)
• Files in Linux filesystem (~/Projects/project)

Worth mentioning that this PC has some tight security config that prevents me from accessing some websites such as Playstation's Store and even some news portals. I have no expertise in network security stuff though.

[dancingmonkey]

I ran into this issue, it was solved by creating the project in the WSL2 file structure instead of the Windows file structure.
Original project that couldn't hot reload was created in C:Usersusername\Documents
Project that was able to utilize hot reloading was created in \wsl$\Ubuntu\homeusername (it's all under a "network device" apparently)
Quick tip for this also, you can open file explorer to your current WSL2 directory by running the command "explorer.exe .". It can also be accessed easily in VS Code by installing the VS Code Remote Development plugin, found here: https://code.visualstudio.com/docs/remote/remote-overview

This worked for me also, thanks! The WSL2 terminal was mounting directly to my Windows 10 user folder by default, so I created my Gatsby project there. After recreating my gatsby project (gatsby new projectname) in the WSL2/Linux file structure, hot reloading worked.

Also, a huge bonus in my case was that my compilation times (after performing a gatsby develop) went down from ~30000ms to ~3500ms.

Thanks so much!! This worked for me!! I quess for now we need to keep the websites inside ubuntu itself on wsl1/wsl2 for hot reloading to work. I had the same issue with Jekyll sites not live reloading, but now it's doing it..happy 👍

[RilDev]

Solved by adding a src/pages/404.js file.

import React from 'react'

const PageNotFound = () => {
  return <>404, page not found!</>
}

export default PageNotFound

[John-Di]

Just in case it helps anyone like me, the fix for my little project was to run a 'gatsby build' before running 'gatsby develop'. No idea why this fixed my hot reload, but it's the only thing that's worked for me after a couple days of searching forums and trying a million different solutions.

Just installed Gatsby and cloned the Hello World starter repo with Node version v10.19.0 on Mac Mojave 10.14.6. Can confirm that running 'gatsby build' and then 'gatsby develop' fixed the issue for me (for now). Much appreciated!

[machineghost]

This seems really wrong. Gatsby's build command is for production: it should have nothing to do with the dev server.

[Neilblaze]

WSL2 is creating issues on hot-reloading. Don't know why, but I followed this, it still doesn't work!

@Microsoft should look into this asap!

[holylander]

Hi friends!

Im running gatsby develop on windows. After trying many things, including wsl, npm clenaup etc, I realized that my antivirus _sophos_ was blocking the webpack hot reload socket __webpack_hmr.

All I had to do is to disable the antivirus for a while. ( You are free to uninstall it or maybe change to another one ).

hope it works for you ;)

[emalindahk]

I had the same problem. What worked for me was to ;

• Delete package-lock.json and node_modules folder
• Run npm install