Blitz.js (Next.js) Fast Refresh not working

#1

Hi!

I am using Gitpod for developing a Blitz.js (based on Next.js) web app. Unfortunately, Fast Refresh is not working in Gitpod. I also found here a post about setting up a webpack-dev-server, but also blitz dev -H "$(gp url 3000 | sed 's+https://++'):443" didn’t work out (Blitz / Next starts with an error).
Any suggestions on how to make it work? My F5 key is getting quite worn :wink:

Best regards,
Kai

#2

:wave: @medihack. Is the project open-source? Could you please share with me a link to the repository (or a repro) and the error message.

edit: I have been able to reproduce over at https://github.com/ghuntley/gitpod-with-blitzjs/tree/master/repro and found the following related items:

Have asked the networking engineers for a consult + advice how to resolve and document the resolution.

#3

@ghuntley Thanks for the help. The problem also affects Next.js (as Blitz.js is based on it). I put up a little example starter app for Next.js as well (https://github.com/medihack/gitpod-next). When editing the pages/index.js normally the fast refresh updates the site automatically, but not in Gitpod. HMR is not working there (in my case it could not connect to https://3000-plum-jellyfish-uk215sfw.ws-eu03.gitpod.io/_next/webpack-hmr?page=/).
As far as I know, Next.js does use its own dev server and not that of Webpack, so the recommended solutions do not work (no disableHostCheck or public option).

#4

We currently have a design problem/choice (internal link) that unfortunately breaks most live-reload systems:

  • we expose HTTP servers behind an HTTPS proxy (requires some config to make web servers work)
  • we don’t expose actual ports on the workspace URL (e.g. red-ox-abc.gitpod:1234) but encode the port into the hostname and use a different port instead (e.g. 1234-red-ox-abc.gitpod:443) – this is super-awkward to configure in live-reload systems)

Seeing what I can do to get this :arrow_double_up: in the roadmap.

2 Likes
#5

Thanks for the update. I really hope you’ll find a solution. If one ever worked with live reloading and especially hot module replacement then it is not imaginable to work without it for a longer period of time.

2 Likes
#6

Hi @medihack!

Thanks for reporting this problem. I haven’t had time to look into a workaround, but maybe there is still something we can do to make live-reload work for Blitz (e.g. with some extra configuration).

If it helps, my usual process goes something like this:

  • Open the web preview in a new tab
  • Open the Network dev tool
  • Look for failed network requests that look like HMR is trying to connect to the wrong place (sometimes you need to wait for some time, or to make some minor change in the code to trigger it)

If your workspace is red-fox-abcd, your web app runs on port 3000 and HMR on port 3001, you’ll typically see that the front-end tries to connect to 3000-red-fox-abcd:3001 (fails/unsupported) instead of 3001-red-fox-abcd:443 (expected).

Sometimes there is a way to configure HMR to work through a proxy (i.e. HMR server runs on localhost:3001, but the front-end web app knows to use 3001-red-fox-abcd:443 instead).

Additionally, I’ve requested a design change/simplification that might fix this entire class of problems (secondary servers on different ports, e.g. HMR/live-reload servers) by exposing ports directly on the root workspace domain and not a separate/“unexpected” domain:

Let’s see if this is something we can reasonably get into the roadmap, or if the change is too involving for now.

If not, we’ll have to continue with the workarounds (some of which are briefly described in the issue).

1 Like
#7

Hello @jan.

Thanks for investigating this issue. The problem is that the Next.js development server (used by Blitz) doesn’t have a lot of options (almost only host and port). Maybe it would work with some kind of custom server (but this will lead to other issues). I also posted a question to the Next.js discussion forum, but no answer yet. I will follow your created issue and hope for the best.

2 Likes
#8

Hi @medihack,

I had a look at GitHub - medihack/gitpod-next and hot module reloading works as expected for me in a Gitpod workspace. I don’t see any recent commits, so I wonder if you still have an issue with HMR on Gitpod.

Cheers,

Mike

#9

I have not tried Gitpod for quite some time but just tried it again now. Wow, a lot has happened. Fash refresh works. I can use docker-compose to spin up containers in my Gitpod. And Visual Studio Code as the main editor. Just wow! It seems you get me back as a customer. Congrats on this great product! :+1:

1 Like
#10

That’s great to hear. The team continues to work on exciting new features, such as a local companion app.

Also, we now have a permalink for our roadmap at www.gitpod.io/roadmap.

Do reach out if we can help in any way.

1 Like