As soon as you put yarn dev or npm run dev behind a https proxy, it's impossible for vite to provide HMR due to a variety of implementation caveats and poor documentation. I could split this bug into several, but it's all HMR and it's confusing set of configuration options and fallbacks.

[Sec32fun32]

As soon as you put yarn dev or npm run dev behind a https proxy, it's impossible for vite to provide HMR due to a variety of implementation caveats and poor documentation. I could split this bug into several, but it's all HMR and it's confusing set of configuration options and fallbacks.

I'm using the vite (2.7.10) + vue-ts template to create a project.

Example 1:

hmr: false

Adding this option to vite.config.js does nothing, or at least nothing I can detect. The front-end still tries to connect to the vite websocket server for hmr, but on the default :3000 port.

Example 2:

hmr: { clientPort: 443 }

This makes the front-end code connect to the correct address, e.g. wss://domain instead of wss://domain:3000. No idea why it's being rejected. The javascript stack isn't useful (client.ts:28)

const socket = new WebSocket(`${socketProtocol}://${socketHost}`, 'vite-hmr')

client.ts:28 WebSocket connection to 'wss://domain.tld/' failed:
(anonymous) @ client.ts:28

Example 3:

Now, this is the most confusing, we have hmr.port and hmr.server.port. The hmr.server options lead me to believe that a separate server would be started if I provide e.g. hmr: { server: { port: 3001 } }. They don't seem to have any effect, only the main service comes online (:3000). It's all guesswork due to the very brief docs for the hmr json schema.

Digging around the code, a server is started if HTTPS options are provided. I don't need to provide HTTPS options as it's being terminated on my own edge servers, but it should be started in http mode too?

Other:

I think hmr.clientPort works, the client protocol is nicely autodetected to wss, there's just a connectivity issue and I can't figure out what.

I've tried returning an error code (404, 500, 502, 503) for /__vite_ping and thereby avoiding the constant reloading on the client, and it seems to be fully ignored by the front end client:

My suggestion would be to create a RFC, document HMR use cases e.g. vite.config.js for the following:

• running standalone on a local dev environment,
• running behind a https edge,
• running the app on one port e.g. :3000, hmr on a different one (:3001, :random)
• simply configure the client endpoint (e.g. wss://domain.tld)
• what is hmr.path, is it just a client-side change? Is it relevant? How?

I'm sorry if the frustration is coming out of the above text, I've spent a day to get this working without errors without success, and my best bet at resolving this is modifiying files in node_modules. When I'm frustrated, I rant. My suggestion would be to implement HMR, or at least the server/client and config part of it, by introducing a RFC process.

It's critical to document common use cases (e.g. standalone, docker, https), and provide better documentation than what exists for HMR currently, and examples to satisfy the above cases. There are a couple of PRs open, which could mitigate my issue. One of them is #6090 where I could disable this retry/refresh behavior, and just live without HMR. Is it great? No. Would I appreciate this being merged when this day started? YES.

Oh and additionally, if you enable middlewareMode, there's a bug along the lines of wsServer.on doesn't exists. I'm unsure what the point was, but if it was attaching an "upgrade" listener for websockets to the default server, it's probablly not passed correctly or something. I was tempted to modify this into wss.on('upgrade'... but it didn't work, apart from getting rid of the notice, it's been a no-op, like all of my work on this today.

If anybody is running HMR behind a third party https proxy (and not localhost/, along the lines of ngrok.io, or an nginx that's terminating SSL) - I'd be very interested in what you had to do to make it work. Some of my workaround attempts involved a nginx-proxy in front, which would route websocket requests to :3001 - before realizing that hmr.server.port has no effect.

Originally posted by @titpetric in #6473