fix: handle websocket connections using experimental deno:request event

[CertainLach]

Fixes: #3350

Requires deno with this PR: denoland/deno#30746

Context:

• Fresh V2 Beta WebSocket upgrade request never reaches server behind vite development environment #3350 (comment)
• Fresh V2 Beta WebSocket upgrade request never reaches server behind vite development environment #3350 (comment)

[CertainLach]

I wish every non-vite request was going through this route, as the current implementation looks too fragile

It is however only required and used for websocket for now.

[DontMash]

@marvinhagemeister
I'm really interested in this fix and would also like to help.
You mentioned (#3554 (comment)) that this change will likely not be merged since

it deviates from the web platform

What would be your approach if intercepting the request is not the correct way.

[marvinhagemeister]

@DontMash Create a Fresh cli that calls vite as a middleware. That's the proper solution. This PR can't be merged because it depends on another PR being merged into Deno itself. The PR for Deno is very unlikely to be merged.

[DontMash]

Create a Fresh cli that calls vite as a middleware.
What do you mean by cli and how to use vite as a middleware?

Should App provide a websocket command to define a websocket route and use vite as a middleware?

As far as I know, the vite middleware can only be accessed when creating a server or configuring a plugin.
That is why I also assumed intercepting the request in the plugin is the best solution.

[CertainLach]

Should App provide a websocket command to define a websocket route and use vite as a middleware?

You don't need to do that with requests being Deno requests, which is default in Fresh

The problem is that vite starts a node.js http server instead, and you can't properly convert node requests back to deno requests, because node.js handles websockets differently

It is possible however to create a vite dev middleware for fresh (I.e app.use(viteMiddleware(viteConfig))), that performs compilation, and responds with built client files from vite's output MemFS (or however it is called there).

[DontMash]

You don't need to do that with requests being Deno requests, which is default in Fresh

I know, but you still need to handle the upgrade yourself. The question was also closer related to meaning of cli in this context

The problem is that vite starts a node.js http server instead, and you can't properly convert node requests back to deno requests, because node.js handles websockets differently

I also tried to convert Nodejs websocket requests to Deno myself.

It is possible however to create a vite dev middleware for fresh (I.e app.use(viteMiddleware(viteConfig))), that performs compilation, and responds with built client files from vite's output MemFS (or however it is called there).

This would mean that just the dev_server would not be part of the plugin anymore, but rather be implemented as a middleware for fresh?

[CertainLach]

This would mean that just the dev_server would not be part of the plugin anymorer, but rather be implemented as a middleware for fresh?

Exactly. It is not quite a middleware, because of how fresh handles build cache updates, but I already did that for webpack and the resulting setup works very well for me, it should work similarly for vite.

[bartlomieju]

Closing — this depends on denoland/deno#30746 which was never merged and is unlikely to be (deviates from the web platform, per maintainer feedback).

The proper fix is for Deno.upgradeWebSocket() to work with node:http upgrade events, tracked in denoland/deno#33220. In the meantime, #3737 provides a working workaround using a second Deno.serve() + TCP proxy.