fix: infer hmr ws target by client location

[sapphi-red]

Description

This PR implements #7977 (comment).
(That comment says "If we default hmr to same port with server" but it was already working like that.)

I created https://github.com/sapphi-red/vite-setup-catalogue and tested all of these setups and it worked without any configuration.
(with-proxy includes a configuration because this repo uses 3.0.0-alpha.12 not this PR)

fixes #3093
fixes #5153
fixes #6814

Cases covered with vite-setup-catalogue

• Basic
• Middleware Mode
• Backend Server
• With Proxy: Vite HMR is unusable behind reverse proxies with random port numbers for client #3093, HMR clientPort option ignored in normal mode  #3737, HMR client port should default to 443 on https  #5153, HMR does not work when using local reverse proxy via Docker/Caddy #6814
• With Proxy (No WebSocket): fix: infer client port from page location #7463 (comment), fix: infer client port from page location #7463 (comment)

Cases not covered with vite-setup-catalogue

• Vite runs behind a reverse-proxy which does not support websocket (fix: infer client port from page location #7463 (comment), fix: infer client port from page location #7463 (comment))
  • It is a breaking change for this setup. Previously it worked without settings. Now it needs to set server.hmr.clientPort = server.port or server.hmr.port = 'something'.
  • To avoid a breaking change: If the connection failed, I think we could fallback to the Vite HMR server. (not yet implemented in this PR)
  • Now it's covered with vite-setup-catalogue and it is not a breaking change for this setup
• Vite runs behind a reverse-proxy and server.hmr.port is set (2.9.1 portsAreCompatible is a breaking change #7545)
  • It is a breaking change for this setup except when websocket is proxied to the same port.

Additional context

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the Commit Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[patak-dev]

This is amazing @sapphi-red: https://github.com/sapphi-red/vite-setup-catalogue
I wonder if we should add all these cases to our CI or maybe add some tests in your repo and connect it to vite-ecosystem-ci.
@lukashass @lbogdan if you have some time, please review and let us know about this approach 🙏🏼
Also @davidwallacejackson, in case you have time to retest with your setup

[sapphi-red]

The with-proxy setup in vite-setup-catalogue requires docker so I think it is better to use vite-ecosystem-ci. (or remove docker)

I need to solve how to make websocket proxy by-passed setup work without configuration.

[patak-dev]

I think vite-ecosystem-ci would be a good place for this 👍🏼
It will only require adding a test file like https://github.com/vitejs/vite-ecosystem-ci/blob/main/tests/marko.ts

[sapphi-red]

I need to solve how to make websocket proxy by-passed setup work without configuration.

I implemented the fallback feature which I said in the description of this PR: "To avoid a breaking change: If the connection failed, I think we could fallback to the Vite HMR server."

[patak-dev]

@lukashass @lbogdan we're merging this PR because it looks like it covers the required cases, and it has been tested in several scenarios thanks to @sapphi-red's new suite. We would like to have this change in the v3 beta (to be released soon) to get proper feedback from the ecosystem. We still have time to modify the default behavior if you find issues with this approach. Please let us know if this works for your use cases.

[patak-dev]

Released as vite@3.0.0-alpha.14 in case, so it should be easier to test 👍🏼

[sapphi-red]

Note to self: I forgot to handle a case when importMetaUrl.port is ''. But surprisingly this actually works.

new URL("ws://localhost:").port // ''
new WebSocket("ws://localhost:") // connects to `ws://localhost`

[naruaway]

I think this fix does not work with provided HMR WS server, which is important case to achieve "single port for everything".
I tried to fix it in #11487