set prettyHost to 0.0.0.0 instead of localhost #2960
#2970
Conversation
in /packages/gatsby/src/commands/develop.js
L258-259
```
if (isUnspecifiedHost) {
prettyHost = `0.0.0.0`
```
This resolves CORS blocking HMR by printing
`Local: http://0.0.0.0:8000/`
to the terminal after `gatsby develop` is run instead of
`Local: http://localhost:8000/`
This may not be ideal resolution of the issue and may break
something else. Perhaps a different, deeper fix is needed.
See testing comments in #2960.
Also in packages/gatsby-source-filesystem/index.js
L3
```
var fs = require(`fs-extra`);
```
got transformed to
```
const fs = require(`fs-extra`);
```
I am thinking during `yarn bootstrap` or `gatsby-dev`, still have 100%
tests passing as before and it’s late so gonna commit this and revisit
in the morning.
|
Deploy preview ready! Built with commit dbc49d6 |
|
Deploy preview ready! Built with commit dbc49d6 |
|
Hey could you try this PR? Just published a new gatsby-cli & gatsby release #2983 |
|
Yes! Closing this one. |
|
Since switching to
|
|
Curious why you're loading a SW for development? Gatsby doesn't do this out-of-the-box. |
|
Seems to be the SocketIO server for hot-loading. The error console shows the error here: gatsby/packages/gatsby/cache-dir/app.js Line 28 in 2bda70e This is the stack trace:
|
|
I have the same issue as #2970 (comment) since upgrading from |
|
Hi @sebdubois @bernhardw please see #2960 (comment) (and more recent) / #2983 (comment) (edit: updated link to correct comment) the decision now boils down to should we use |
|
Yes my workaround is to replace Gatsby develop with Gatsby develop -H localhost, but I guess a proper fix is needed. |
|
I'm not sure if this is the right place to fit my comment in, but I thought it would fit: I'm using gatsby-cli in a docker container, and in order to use it as development tool you normally would do something like:
(assuming in $(pwd) is an gatsby project created with gatsby new - works btw fine with docker) but this doesn't work (visiting localhost:8978 gets an ERR_EMPTY_RESPONSE) In order to make this work you have to add final command looks like: "dependencies": { You could check out the Dockerfile here Maybe this is a special use-case and only for me interesting, but I thought I share this so it maybe could considered somehow. |
|
@KyleAMathews Let me know if there is something I can do docs-wise to illuminate this and save people trouble, happy to PR |
|
@pandorasNox have you gotten this to work with HMR ? I can't seem to make it work with a docker-compose setup with |
|
@lasseborly unfortunately HMR wasn't working with this setup. It would be awesome if we get this to work with docker. Maybe this problem is more webpack related. Could you share the docker-compose file? |
|
@pandorasNox to make this work, do not change the port. HMR doesn't know about the port you chose. This works for me: version: "2"
services:
node:
build: .
ports:
- "8000:8000"
volumes:
- ./:/code
working_dir: /code
tty: true
command: bashThen, in container, run gatsby as you mentioned before: gatsby develop -H 0.0.0.0
|
|
@ujovlado hey thanks for your input, got HMR working I used: so the trick is (again thanks to @ujovlado ) to use the same ports in docker and in gatsby if your port 8000 is free the docker port part |
in /packages/gatsby/src/commands/develop.js
L258-259
This resolves CORS blocking HMR by printing
Local: http://0.0.0.0:8000/to the terminal after
gatsby developis run instead ofLocal: http://localhost:8000/This may not be ideal resolution of the issue and may break
something else. Perhaps a different, deeper fix is needed.
See testing comments in #2960.
Also in packages/gatsby-source-filesystem/index.js
L3
got transformed to
I am thinking during
yarn bootstraporgatsby-dev, still have 100%tests passing as before and it’s late so gonna commit this and revisit
in the morning.