vercel: [now dev] Reloading not supported on CRA project

now dev then spins up it’s own server and proxies request to the underlying CRA dev server.

I have noticed that the /sockjs-node websocket requests never get proxied correctly, and therefore we can’t support auto page reload, or react hot loader / react fast refresh (via react app rewired).

Observations

It appears that when running now dev it actually makes the underlying CRA dev server run on a random port, for e.g 49426. The actual now dev server runs on the typical port that CRA would normally run on, i.e. 3000. This confused me a bit but I eventually figured out what was going on.

That all being said, if I load the CRA dev server directly (i.e. utilising the random port, e.g. 49426) then I notice the /sockjs-node requests resolving correctly. It’s only when I use the now dev proxy server (i.e. 3000) that the requests do not resolve.

Steps to reproduce

Create a new black CRA project

Add the script:

"dev": "BROWSER=none react-scripts start"

Run now dev
Open browser on http://localhost:3000
Open dev tools and note the /sockjs-node request never resolving

Without this request proxying correctly we can never get hot reloading working as rad as it could. With the new React Fast Refresh around the corner it would be great to get the now dev server ready to support this.

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 7
Comments: 17 (9 by maintainers)

Commits related to this issue

[now-cli] Support WebSocket upgrades in `now dev` We were already using `http-proxy`'s WebSockets option, but we were missing a step! In addition to setting `{ws: true}`, you must also forward WebSoc... — committed to matchu/vercel by matchu 4 years ago
[cli] Support WebSocket upgrades in dev (#4241) We were already using `http-proxy`'s WebSockets option, but we were missing a step! In addition to setting `{ws: true}`, you must also forward WebSocke... — committed to vercel/vercel by matchu 4 years ago

Most upvoted comments

I think I got this one! My theory wasn’t actually true; the multiple instances of the proxy server weren’t the culprit! Instead, it’s just that we were missing a step for WebSocket support: {ws: true} by itself isn’t enough!

matchu on May 2, 2020

@hamstu yep it’s on my fork, in review as PR #4241!

matchu on May 5, 2020

Yes we have a contributing doc here: https://github.com/zeit/now/blob/master/.github/CONTRIBUTING.md

Looks like it needs to be updated. For your purposes, this should work:

git clone https://github.com/zeit/now
cd now
yarn install
yarn build
cd ./packages/now-cli
yarn test-integration-dev

The cli bin is located at ./packages/now-cli/dist/index.js.

styfle on Apr 27, 2020

Hi hi, I’m having this issue but it’s even worse in Firefox (76)! The sixth time I load the page, the whole proxy server stops responding to requests and requires two Ctrl-Cs to kill instead of one 😬

My hypothesis is that this is because Firefox handles the socket issues differently, and keeps the problematic sockets open, whereas perhaps Chrome hangs them up? And so then we hit Node’s default limit of 5 open sockets for a given host.

I can work around it for now by switching to Chrome, but just fyi that this was a pretty disruptive newcomer experience for me, and might be worth increasing the priority for that reason! It took me a while to learn enough to find this issue or to consider that changing my browser could do anything 😅

matchu on Apr 23, 2020

Hi @ctrlplusb

I just tried this with the Now CLI Canary and it worked correctly. I believe this was fixed in Now 17.

The canary channel has another fix (#3903) that makes the url/port a little more clear.

npm i -g now@canary

Does this fix your issue?

styfle on Mar 11, 2020

FYI…

@rauchg reached out on twitter and said the team is fully aware of this. ⭐️

ctrlplusb on Jan 6, 2020