Using pow (virtual host proxy) causes websocket error

[thom-nic]

Description

When using pow with create-react-app's dev server configuration, the dev server attempts to make a websocket connection via the virtual host (e.g. uses window.location.hostname.) Pow does not handle websocket proxying, thus the dev server client connection needs to be made directly to localhost:[dev server port].

Observed behavior

The dev server websocket connection fails, resulting in the following browser console error:

WebSocket connection to 'ws://foo.dev/sockjs-node/414/5glaoex2/websocket' failed: Connection closed before receiving a handshake response

after which it appears to fall back to the xhr long poll method.

Desired behavior

With the standard webpack dev server HMR setup one would configure the client URL for the websocket to use. e.g. in webpack.config.dev.js:

  entry: [
    // create-react-app uses this:
    // require.resolve('react-dev-utils/webpackHotDevClient'),
    // "standard" approach:
    'webpack-dev-server/client?http://localhost:9999',
    'webpack/hot/only-dev-server',
    'app.js',
  ],

So while browsing the app at foo.dev the client websocket connection is made to localhost:9999 and everything is peachy. This is not currently possible with react-dev-utils/webpackHotDevClient meaning if a user wants to use create-react-app and pow together, they must either...

1. eject and swap out react-dev-utils/webpackHotDevClient for the standard dev tools HMR configuration, or
2. put up with the console error in the browser - which is not ideal because it's more difficult for a user at a glance to determine if there are actual application errors in the client.

Feature request: Add ability to specify the direct dev server URL in the client entrypoint similar to 'webpack-dev-server/client?http://localhost:9999'.

Environment

create-react-app version: 0.2.0

Reproducible Demo

# install/ setup pow
create-react-app myApp
echo 3000 > ~/.pow/foo
npm start & open http://foo.dev

[onpaws]

I find pow a valuable tool that saves me significant cumulative overhead when juggling projects. Probably most developers work on >1 project and it's just a big time saver.
Would love to better incorporate it in my React work.

Having proper pow support as sanctioned through create-react-app would be sweet.
Happy to beta test on this.

[gaearon]

Does this other tool help?
basecamp/pow#506 (comment)

[thom-nic]

I did see that issue and mention of puma-dev (and mehserve) but TBH have not tried either one yet. To be clear, the request here is to be able to configure the websocket URL that the injected client uses. That ability would happen to work around Pow's lack of websocket support.

[gaearon]

I understand that the request is to allow configuration but this defeats the purpose and philosophy of Create React App. If you're happy configuring low-level things like this, using webpack directly might work better for you.

On the other hand, if we can fix it for everyone without configuration, or if we can suggest better tooling to work with Create React App, we'll gladly do that.

[thom-nic]

Fair enough. Do you think it makes more sense to force the hot-reload client to always use ws://localhost:[port] instead of window.location.hostname? Does anyone use the hot reload dev server other than on localhost?

[gaearon]

If you can send a PR I could take a look.

[gaearon]

But AFAIK, yes, we support specifying custom hostname for virtual hosts.

[thom-nic]

I need to look into this, I found the line where the client uses window.location.hostname to build the websocket connection URL. Maybe that was just the default but I didn't notice anything that looked like a configurable override. I'll dig a little deeper.

[fjeldstad]

I would really like to be able to override the hot-reload client address as well; in my case the index.html is actually hosted within a separate app (Dynamics CRM) potentially located on another machine but it would be convenient to be able to load the script bundle from the Webpack dev server on localhost during development.

The tricky part with using hard-coded defaults (like localhost instead of window.location.hostname) is that the user could have used the HOST and PORT environment variables to control the dev server address. And to make things a bit more complicated, ��the port could be something else than either 3000 or process.env.PORT, since the start script asks the user if a different port should be used when the default one is unavailable. So I don't see how hard-coding the address would "work for everyone", unfortunately.

[gaearon]

I'm going to close this for lack of activity. If there are any specific PRs we could consider them. However this tool is not meant to cover all possible use cases: it's meant mostly as a starting point. So you should probably eject and use webpack directly if you need more control.

[thom-nic]

After considering this more I think I agree, ejecting seems to make the most sense since the purpose is to provide defaults not a fully configurable framework.

[scisci]

This is something I just found out I needed. It would be nice if at least it could match the host set in .env . My issue is that my server is running in a docker container, but I have my front-end hot-reloading from my host computer via a reverse proxy.

Note: I was able to get this working by also running a reverse web socket proxy, but it seemed to me that if the HOST is an option as an env variable, then shouldn't the websocket use that host?

[gaearon]

Send a PR if you can get it working ;-)