HMR clientPort option ignored in normal mode

[NickClark]

Describe the bug

When using Vite behind a proxy, it would be nice to set the client port. I had it working when using SvelteKit, but I decide Vite alone would be more appropriate for my SPA. Found that the same server.hmr configuration didn't work. It appears that clientPort is only considered if in middleware mode.

Reproduction

import { defineConfig } from "vite";
import svelte from "@sveltejs/vite-plugin-svelte";

export default defineConfig(({ command, mode }) => {
  const isProduction = mode === "production";

  return {
    plugins: [svelte()],
    server: {
      strictPort: true,
      hmr: {
        clientPort: 443,
        port: 5001,
        protocol: "wss",
        path: "/vite",
      },
    },
  };
});

System Info

  System:
    OS: Linux 4.19 Ubuntu 20.04.1 LTS (Focal Fossa)
    CPU: (24) x64 AMD Ryzen 9 5900X 12-Core Processor
    Memory: 10.69 GB / 24.99 GB
    Container: Yes
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.2.0 - ~/.asdf/installs/nodejs/16.2.0/bin/node
    npm: 7.13.0 - ~/.asdf/installs/nodejs/16.2.0/bin/npm
  npmPackages:
    vite: ^2.3.7 => 2.3.7

[asaf]

this is important, without this it's impossible to run vite behind an https proxy,

I had to workaround this by patching client.js:

const socket = new WebSocket(`wss://my-host/myapp`, 'vite-hmr');

[plashenkov]

Hmmm, for some reason, using server.hmr.port = 443 works for me. I'm using Vite dev server behind an nginx, and autoreloading seems to work. I do not know internals though.

Nginx config:

server {
  listen 443 ssl http2;
  listen [::]:443 ssl http2;
  server_name (...);
  ssl_certificate (...);
  ssl_certificate_key (...);
  proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection 'upgrade';
  proxy_set_header Host $host;
  proxy_set_header X-Forwarded-Proto $scheme;
  location /admin {
    proxy_pass http://vite_server:3000;
  }
}

Vite config:

export default defineConfig({
  plugins: [vue()],
  base: '/admin/',
  server: {
    host: true,
    port: 3000,
    strictPort: true,
    hmr: {
      port: 443,
    }
  }
})

Also, on my local dev machine Vite dev server throws an error when server.port = 80 (as expected), but it starts without problem when server.hmr.port = 80. Does this mean that it doesn't try to start HMR server on port 80 and just uses this value to pass it to a browser?

[plashenkov]

Okay, if I understand the code correctly, in standard, non-middleware mode, there is no separate server for HMR created (until you specially create it and specify in server.hmr.server option):

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

Lines 26 to 38 in 24178b0

	const hmr = typeof config.server.hmr === 'object' && config.server.hmr
	const wsServer = (hmr && hmr.server) || server
	if (wsServer) {
	wss = new WebSocket.Server({ noServer: true })
	wsServer.on('upgrade', (req, socket, head) => {
	if (req.headers['sec-websocket-protocol'] === HMR_HEADER) {
	wss.handleUpgrade(req, socket, head, (ws) => {
	wss.emit('connection', ws, req)
	})
	}
	})
	} else {

And here you can see that the server.hmr.port option is taken (see the line after else) and then simply passed to the client side:

vite/packages/vite/src/node/plugins/clientInjections.ts

Lines 27 to 34 in 7db69a3

	if (config.server.middlewareMode) {
	if (typeof config.server.hmr === 'object') {
	port = config.server.hmr.clientPort || config.server.hmr.port
	}
	port = String(port || 24678)
	} else {
	port = String(options.port || config.server.port!)
	}

For the middleware mode, server.hmr.port is used to create a real http server on that port. As for the client side, server.hmr.clientPort can be used to override the real server port value.

To summarize

In non-middleware mode the server.hmr.port option can be used for overriding, for middleware mode — server.hmr.port is really used, and server.hmr.clientPort can be used for overriding.

It looks like there can be confusion with such fuzzy usage of options, and some unification would be fine.

@johnnysprinkles @Shinigami92

[plashenkov]

@Cretezy Great, it works! Thank you!

[johnnysprinkles]

Thanks for fixing, when I added that I didn't really know what middlewareMode is (actually I guess I still don't), and just got it working for my own use case.