This looks good to me @lukashass, thanks for working on the PR.

@mehulmpt, @edorgeville maybe you could also check this PR is working for you?

@patak-dev Can you rerun the CI?
I'm unsure if the test failure is related to this PR. The tests are working locally.

See comment #7463 (comment), @jeoy let's merge this one to avoid introducing a new option if it isn't needed. Please create a new PR if we're missing something here to add the option back and let's re-discuss it. Thanks!

@lukashass thanks again for digging into this ❤️

So does this make it impossible for our setup to work when we have a Java server running on port 8080 and a Vite server running on a random port and want the browser to make the websocket connection directly to the Vite server?

@Artur- thanks for testing, let's revert this PR so we can release 2.9 today. @lukashass we can try this fix again taking into account @Artur- case later.

@Artur- Are you integrating the vite page in an iframe? I think to cover that case, we have to infer from import.meta.url instead of location

Edit: I just found out that vite works just fine in an iframe, since location is scoped per iframe.

No iframe. We are proxying the Vite requests through a /VAADIN/ url on a Java server so that when your app is running on localhost:8080, the browser will request localhost:8080/VAADIN/index.html -> http://localhost:8080/VAADIN/@vite/client etc. Proxying the websocket connection though seems like an unnecessary hassle in our case as the Vite server is available to the browser using localhost:12345 or whatever port it is running on. So far it has always worked fine that ws://localhost:12345 is used for the websocket connection in the browser. I guess that hmr.port: false would solve our case if it was kept around

I'm in the same situation as @Artur-.

I often embed my live apps in subdirectories (or even within larger pages) of my server-side applications. The live apps will therefore load on http://localhost:8080 but vite is still expected to directly connect to its own port. This PR would break that.

It's easy to fix this by setting hmr.clientPort – the behavior will then revert to how it is now. I've tested this and it works fine. But it's definitely a breaking change and might cause some unexpected behavior for others.

I have two ideas on how to proceed:

• I like the approach in feat(config): hmr add disable port config #6624 because it makes this an opt-in behavior and my existing configurations will continue to work, although I would personally want to see something a bit less ambiguous such as clientPort: 'infer'.

• If we really want to change the default behavior (this is certainly more ideal because it matches the behavior of other devservers) then @Artur- and I can set e.g. hmr.clientPort: 12345 to include the port. It might be worth adding a case for clientPort: 0 to automatically match the port so we don't need to specify and change the same port twice.

To @baileyherbert 's points, fixing this with an opt-in configuration doesn't really make sense, as we can already do that by using clientPort. So I strongly think this should be the default behaviour - even with the drawback of breaking a few existing environments, this might be easily mitigated, either by sticking with a previous working vite version, or configuring clientPort accordingly.

I work at CodeSandbox, and our use-case is that we reverse-proxy from an URL like https://${id}.sse.codesandbox.io/ to a vite devserver running inside a container sandbox, basically breaking HMR for all users that want to use vite inside CodeSandbox. As an aside, their initial reaction is also to blame it on us 🙂 - which only makes sense, because they expect for it to work the same as in a local environment.

A better inference, that combines both this and #6624, and might coincidentally fix @Artur- and @baileyherbert 's use-cases, is simply: if location.port is empty (''), then don't use a port for the websocket URL, otherwise use __HMR_PORT__.

So if vite is listening on localhost:12345, you're proxying to it from localhost:8080, and you're opening http://localhost:8080/ in the browser, because location.port is not empty ('8080'), we use __HMR_PORT__, and the inferred websocket URL would be ws://localhost:12345/. A weird artefact is it would break if you're trying to proxy to vite from localhost:80 - because, even if trying to open http://localhost:80/, the browser would just strip out the default http port (TIL!), and the inferred websocket URL would end up being ws://localhost/.

This would also work for our use-case - the websocket URL for https://${id}.sse.codesandbox.io/ would be wss://${id}.sse.codesandbox.io/. Although it would break for https://${id}.sse.codesandbox.io:443/, as noted above, the browser would just strip out the default https port, so it's not an issue.

Nice idea!! That would work perfectly for me. 👍

Yesterday, I tried tunneling vite through Cloudflare Argo to quickly share a project with a colleague. I couldn't get it to connect with the vite backend on both the tunnel something.trycloudflare.com:443 and localhost:3000 simultaneously due to this constraint. This should absolutely work out of the box.

Yet, say you're running a large project on localhost:3000 and it's proxying to multiple vite projects on 3001, 3002, etc. This would also work out of the box with your proposal. I love it! Just need to make sure that clientPort can override this behavior for those who try the same thing on ports 80 or 443.

I think we could make it work if we expose to the client the fact that clientPort was explicitly set - right now the client just gets __HMR_PORT__, without knowing if that was explicitly set with clientPort or not. So the logic would be something like:

if (clientPort explicitly set || location.port !== '') {
  use __HMR_PORT__
} else {
  don't use a port
}

Considering the use-cases of @Artur- and @baileyherbert, this really is about finding a better default rather than just fixing the existing behaviour 🤯

After reading your ideas I came to the following possible values for clientPort:

'auto' (default)

I really like @lbogdan's idea of only inferring the port on default ports as this will probably cover most proxy setups while only breaking very few 🤞 existing setups.

I would suggest a possible variation: (additionally) use location.hostname !== 'localhost' to decide on inferring. If you are accessing an application via localhost you probably also have direct access to the vite port, if not then your proxy can likely handle the websocket 🤔.

number

An explicit number for advanced setups. (basically what is possible now)

'infer' (convenience)

Force inferring the port even if localtion.port !== ''

This can also be done by setting the clientPort to the desired port. Hence this would only be for convenience, so you don't have to adjust this every time your proxy config changes.

'server' (convenience)

Force using vite's port for the client connection even if localtion.port === ''

This can also be done by setting the clientPort to the same port as vite. Hence this would only be for convenience, so you don't have to adjust this every time your vite port changes.