2.9.1 portsAreCompatible is a breaking change

[jeoy]

Describe the bug

vite/packages/vite/src/node/server/ws.ts

Line 35 in c7fc7c3

const wsServer = hmrServer || (portsAreCompatible && server)

When access dev server from domain(www.mydomain.com) not localhost:xxxx, websocket always connect failed.

And It works in v2.8.6

my vite config

  server: {
        hmr: {
            port: 80,
        },
    },

I highly recommended Revert this PR #7282

Reproduction

Critical bug

System Info

System:
    OS: macOS 10.15.7
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
    Memory: 113.89 MB / 16.00 GB
    Shell: 5.7.1 - /bin/zsh
  Binaries:
    Node: 16.14.0 - ~/.nvm/versions/node/v16.14.0/bin/node
    Yarn: 1.22.17 - ~/.nvm/versions/node/v16.14.0/bin/yarn
    npm: 8.3.1 - ~/.nvm/versions/node/v16.14.0/bin/npm

Used Package Manager

yarn

Logs

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/core instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[patak-dev]

@jeoy any chance of creating a minimal reproduction? It would be good to try to see if a fix is possible before reverting

[benmccann]

I don't quite understand your setup. Do you have a load balancer / proxy in front of your Vite dev server that is serving port 3000 as www.mydomain.com port 80?

[gudleik]

Experienced same issue after updating from 2.8.6 to 2.9.1. We run vite apps on Docker in Kubernetes and Tilt.dev.
Vite runs on 8080, while the ingress listens on 80, and we use http://lvh.me to access the app.

Solved it by setting port to 8080 and clientPort to 80.

diff --git i/app/auth/vite.config.ts w/app/auth/vite.config.ts
index c312415b3..1b343e297 100644
--- i/app/auth/vite.config.ts
+++ w/app/auth/vite.config.ts
@@ -13,7 +13,8 @@ export default defineConfig({
   },
   server: {
     hmr: {
-      port: Number(process.env.VITE_HMR_PORT),
+      clientPort: Number(process.env.VITE_HMR_PORT),
+      port: 8080,
     },
   },
   resolve: {

[jeoy]

@jeoy any chance of creating a minimal reproduction? It would be good to try to see if a fix is possible before reverting

it's quite difficult to show a minimal reproduction cause it need a domain in front of Vite dev server.

I think @gudleik explain this issue clearly.

At least it's a breaking change.

[bompus]

Broke me as well. I just changed hmr.port to hmr.clientPort and it is working again behind my reverse proxy setup. It seems that hmr.port now inherits from server.port, so that part is better at least.

[fatso83]

@benmccann If you want a reproducible test case you can have a look at the repo I created for #7562 :
https://github.com/fatso83/issue-reproductions/tree/master/vite-2.9-server.hmr.port

The fix mentioned in my reported issue works for us, btw, simply replacing port with clientPort.

Our setup looked like this:

• Browser -> Java BE (on port 3000) -> Vite (on server.hmr.port )

By doing it like this the frontend did not have to know/adjust for anything Vite related: that would all be handled on the BE, which can either use a prebuilt bundle or proxy to Vite depending on a config switch.

[moisesbites]

@bompus

Broke me as well. I just changed hmr.port to hmr.clientPort and it is working again behind my reverse proxy setup. It seems that hmr.port now inherits from server.port, so that part is better at least.

// svelte.config.js
// ...
	vite: {
			server: {
				host: true,
				port: 3000,
				hmr: {
					host: 'localhost',
					protocol: 'wss',
					clientPort: 443
				}
			}
		}
// ...

It's working for me now. Change 'port' to 'clientPort' It's not reloading anymore. Thank you.

[lbogdan]

@patak-dev Is there a reason why the use-case where the vite devserver is behind an https reverse-proxy (seemingly more and more popular due to remote development) doesn't work out of the box - in regards to HMR - and needs the special server: { hmr: { clientPort: 443 } } config?

It should be pretty straightforward to infer the websocket URL from document.location, e.g.

• local: http://localhost:3000/ => ws://localhost:3000/

• https reverse-proxy: https://some.frontend.doma.in/ => wss://some.frontend.doma.in/

Would you be open to a PR that makes this use-case work out of the box?

[lbogdan]

@patak-dev Digging into it a bit more, I see that was already implemented in #7463, but you reverted it in #7522 - because of a user complaint (cc @Artur-). While I think backwards compatibility should be paramount for such a popular project, I also think this was an important fix for a lot of remote development use-cases (I work at CodeSandbox, and the fact HMR in vite doesn't work out of the box confuses a lot of users).

Is there anything we can do to move this further?

[patak-dev]

Hey @lbogdan! As you mention, this is an important use case and it is a pain point for a lot of users in Vite. I agree that if possible, it should work out of the box.

We're working on Vite 3 right now (a beta would be out probably in 20-30 days). So we have the opportunity to introduce breaking changes in it. If you would like to help us move this further, the best thing would be to work on a PR that reinstates #7463 (or a similar approach) but work in @Artur-'s setup or has an easy way for them to configure it when they migrate to 3.0

[lbogdan]

Hey @patak-dev, thanks for the quick reply, I just shared a possible approach here - sorry for being all over the place, it seems like there's a lot of related issues and PRs 🙂.

[patak-dev]

No problem, thanks for looking into this! Sounds sensible, but I'm not used to these setups myself. I could help push it forward by involving others in the ecosystem to check a PR that would make most common cases work out of the box, and allow more esoteric setups to work by configuration. Let's take the opportunity of Vite 3 to fix this.

[lbogdan]

Completely agree! I also think a documentation section describing how HMR works, the list of setups supported out of the box, and the required configuration for more esoteric setups might also help a lot of people.

[sapphi-red]

Closing as #7282 won't be reverted and #8650 has improved port inference.