Repository navigation
Using pow (virtual host proxy) causes websocket error #853
Description
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...
- eject and swap out
react-dev-utils/webpackHotDevClientfor the standard dev tools HMR configuration, or - 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
Activity
onpaws commentedon Oct 10, 2016
I find
powa 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
powsupport as sanctioned throughcreate-react-appwould be sweet.Happy to beta test on this.
gaearon commentedon Oct 11, 2016
Does this other tool help?
basecamp/pow#506 (comment)
thom-nic commentedon Oct 11, 2016
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 commentedon Oct 11, 2016
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 commentedon Oct 11, 2016
Fair enough. Do you think it makes more sense to force the hot-reload client to always use
ws://localhost:[port]instead ofwindow.location.hostname? Does anyone use the hot reload dev server other than on localhost?gaearon commentedon Oct 11, 2016
If you can send a PR I could take a look.
gaearon commentedon Oct 11, 2016
But AFAIK, yes, we support specifying custom hostname for virtual hosts.
thom-nic commentedon Oct 13, 2016
I need to look into this, I found the line where the client uses
window.location.hostnameto 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 commentedon Oct 18, 2016
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
localhostinstead ofwindow.location.hostname) is that the user could have used theHOSTandPORTenvironment variables to control the dev server address. And to make things a bit more complicated, ��the port could be something else than either 3000 orprocess.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 commentedon Nov 20, 2016
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 commentedon Nov 20, 2016
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 commentedon Feb 16, 2017
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 commentedon Feb 17, 2017
Send a PR if you can get it working ;-)
scisci commentedon Feb 18, 2017
Hey @gaearon, thanks. I submitted a pull request here #1588 hopefully it can get through!