gatsby: TypeError: Cannot read property 'address' of null

I’ve started getting this error when running gatsby develop:

error UNHANDLED REJECTION


  TypeError: Cannot read property 'address' of null

  - develop.js:371 _callee3$
    [StateOfJS]/[gatsby]/dist/commands/develop.js:371:38

  - next_tick.js:131 _combinedTickCallback
    internal/process/next_tick.js:131:7

  - next_tick.js:180 process._tickCallback
    internal/process/next_tick.js:180:9

I’m on Mac OS High Sierra with Node 8.9.1. I first got the error while using Node 9 so I downgraded and the error went away, but I noticed that hot module reloading wasn’t working. From reading #864 I got the idea to try gatsby develop --host localhost --port 8000 instead of gatsby develop, but then that triggered the address error again.

I’m not sure what’s going on exactly… Could it be related to my own config somehow?

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 3
  • Comments: 44 (36 by maintainers)

Most upvoted comments

With the latest version atm of Gatsby, Gatsby-cli, running gatsby develop produces : On Windows, a link to localhost is generated, HMR is working, no CORS issue. On Mac, a link to locahost is generated, HMR is broken, CORS issues are showing. After launching the site this way, on Mac if you navigate to 0.0.0.0:8000 then everything works and no CORS.

My 2 cents on this : localhost is more widely supported, and the fact that 0.0.0.0 doesn’t exists on Windows, makes localhost a better candidate in my opinion.

You’re absolutely right. I guess it’s my fault for not looking at the whole thread more carefully. It does work with gatsby@latest. I’d like to point out however, that gatsby-starter-blog is still using v1.9.118, which is why I got that error above. If you’d like, I can make a PR to fix that issue over at gatsbyjs/gatsby-starter-blog!

@benforshey @artfaktor thank you both for testing!

@SachaG (+ others on Mac) are you seeing secure origin Chrome errors in my #2983 comments? Any opinion on localhost vs 127.0.0.1 as future default Mac/*nix dev URL vs lobbying Chrome for inclusion of 0.0.0.0? @sebastienfi ? Guess we need to decide whether to open new issue or continue that discussion here, @KyleAMathews (+ everybody) you have a preference?

Opened #2970 swapping 0.0.0.0 in for localhost as prettyHost in isUnspecifiedHost section of /packages/gatsby/src/commands/develop.js L259. This restores HMR in URL printed to terminal post-gatsby develop because ends up printing Local: http://0.0.0.0:8000/. This matches host (0.0.0.0) of requests getting blocked by CORS as cross-site due to localhost mismatch described above and by @benforshey in https://github.com/gatsbyjs/gatsby/issues/2956#issuecomment-345560772 It’s a fix, but may not be the right fix. Maybe we want to solve the opposite way or this could be only a symptom or part of a larger problem. Hope it helps @SachaG @KyleAMathews @kildareflare @Magneticmagnum @artfaktor

Thought I remembered Windows having to do with the change. Seems using 0.0.0.0 in place of localhost in the browser (which one can do without touching the code, just do not specify host or will get error) is only a temp. workaround for Mac/Unix devs who need HMR right now.

Means we need to figure out where/why defaultHost from gatsby-cli (0.0.0.0) ends up being set as host for font serving and HMR update json and thus conflicting with prettyHost in develop.js, which leads to the compatible but distinct URIs not passing CORS origin check during development on a Mac. This may overlap what is also causing similar issues on Windows, the error when passing host part especially.

@artfaktor, @sebastienfi, so on Windows you can both gatsby develop but HMR is broken? What happens when you pass gatsby develop --host localhost? Compile error Sacha posted originally? (Same as passing --host bob.dev for me.) No pressure, I should be able to test on Windows tonight, thanks again 😃

Edit: remove en dash add back auto-converted hypens

Thanks everyone for all your efforts to try and rectify this issue. Swapping ‘0.0.0.0’ in for ‘localhost’ as prettyHost didn’t make any difference for me. I still get the error message. Perhaps because I’m on Windows. I’m not a developer so can’t help with investigation unfortunately. Thanks.