HMR proxy for ViteDevMiddleware

[sbakharev]

Vite's docs state that:

With the default configuration, reverse proxies in front of Vite are expected to support proxying WebSocket. If the Vite HMR client fails to connect WebSocket, the client will fall back to connecting the WebSocket directly to the Vite HMR server bypassing the reverse proxies

If the server section is absent in vite.config.js then the fall back logic fails (tested in v5.0.10) - it retries connection using the "ws://localhost:undefined/" URI. As a result, enabling HMR currently requires explicit configuration:

export default defineConfig({
  server: {
    port: 5173,
    strictPort: true,
    hmr: {
      port: 5173,
    },
  },
}

This looks like a bug of Vite to me (I would have used the same default server port for HMR fall back), but I've anyway implemented the solution they describe as expected.

If a WebSocket request contains the appropriate subprotocol then ViteDevMiddleware delegates it to a minimalistic WS proxy ViteDevHmrProxy.

Unfortunately I haven't found any good method to check if UseWebSockets() has already been used during pipeline configuration, so I've also mentioned this call in READMEs.

[sbakharev]

I've edited my initial post multiple times after figuring out some details on how Vite and the middleware work but the idea to support WS proxying remains actual - you no longer need to configure the port in Vite settings.

[Eptagone]

Hi @sbakharev, could you also add an example project using websockets? I would like to analyze it in an example project.

[sbakharev]

Hi @Eptagone!

Sorry for my delayed response.

I've failed to reproduce the problem using existing basic examples. For some reason even when the server section is missing in vite.config, the HMR connection is anyway established directly - using actual Vite's port (not the port used by the dotnet app itself), thus bypassing the middleware (even the fallback logic not triggered). So I don't think it's worth adding a separate example into the source code, because the case my PR fixes seems to be somewhat specific.

I've made a very simple repro project: Vite.AspNetCore.BrokenHmr.zip

I'm new to all this so probably missing something. Hope you can figure out why it fails with HMR.

Steps:

• place the project dir next to the root dir of Vite.AspNetCore repo without my fix
• dotnet run the project
• navigate to http://localhost:54000 with Chrome

Result:

• dotnet app triggers Vite autorun at http://localhost:5173 (we don't reconfigure this anywhere, so it uses default)
• HTML and all resources are loaded, the page is fine
• but Chrome console reports two WS connection failures:

  [vite] connecting...
  client.ts:78 WebSocket connection to 'ws://localhost:54000/' failed: 
  client.ts:78 Uncaught (in promise) DOMException: Failed to construct 'WebSocket': The URL 'ws://localhost:undefined/' is 
  invalid.
  at setupWebSocket (http://localhost:54000/@vite/client:465:20)
  at fallback (http://localhost:54000/@vite/client:444:22)
  at WebSocket.<anonymous> (http://localhost:54000/@vite/client:480:13)

Now if you use the code version with my fix then the WS connection would succeed with the first try and HMR would start working.

[sbakharev]

@Eptagone just interested. Have you figured out what was specific about my sample so it has been failing and other examples have not?