+1, vite-plugin-terminal would also benefit from this feature.

About import.meta.hot.send(...), should we use instead import.meta.vite.send(...)? This feature isn't related to hmr, no?
Or maybe import.meta.dev.send if we want a name that others tools could use

import.meta.vite.send sounds like a good idea. If we do so, we might be able to directly expose the socket and other info as well?

Yes, probably some events could also be exposed in import.meta.vite.on(). 'vite:error' for example, information about the module graph also could be interesting?

Guess we could discuss the general idea of import.meta.vite in the next meeting. If we want the ability for client-server communication, I'd also like to see the support on the server-side for handling the WebSocket connections. And ideally, a standardized way to pass custom data. (so we could even hook birpc with it :P)

For reference, we talked about the proposal and we are going to move forward with import.meta.hot.send(). Moving forward we should interpret hot as "APIs related to the dev server".
We should add an example about how to receive the message on the server as part of the new docs.

Working on the server api

I'm wondering if the hot.send API should match the send server-side API. So instead of hot.send(event, payload), using:

hot.send({ type?, event?, data })

type could default to 'custom', so in general we will be using hot.send({ event, data }). This would leave the door open to send Vite-specific events like hot.send({ type: 'restart' }) (that could be useful for debug utils).

I saw that you already added the 'custom' type in the messageBuffer. Or are you thinking we could have prefixed events like hot.send('vite:restart', payload) in the future?

Great improvement! I've been thinking of a Vite-based CMS for years and this makes it much more real!