vitejs
feat: support unix socket for dev server
Description
Feature to support what is described in #674
Additional context
What is the purpose of this pull request?
- [ ] Bug fix
- [x] 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.
- [x] 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.
@truongsinh Seems there are typescript build errors 🙁
Please fix them, so we can proceed further
@truongsinh : This is actually fixed in newest version https://vitejs.dev/config/#server-hmr
@truongsinh : This is actually fixed in newest version https://vitejs.dev/config/#server-hmr
@matsgm The link does not show this is fixed at all, unless this is a undocumented feature, and you are linking to the documentation. This is not helpful.
Any update on this guys? Was this actually implemented, but not documented yet?
Very interested in this. Any plans to ship it? Lack of unix socket support makes it challenging when working on remote machine
This is my vite.config.ts configuration, which works as describe I think...
server: {
base: '/',
port: 8080,
hmr: {
host: 'localhost',
protocol: 'ws',
},
fs: {
strict: false,
},
origin: 'http://localhost:8080',
},
```
I took a shot at rebasing this PR onto modern Vite, then played around with exposing ListenOptions as a whole, but numerical ports seem to be baked in pretty deep.
Taking "Think Before Adding Yet Another Option" to heart I decided to try implementing this through a plugin instead. Turns out that's much easier, and I just published vite-plugin-serve-ipc. I haven't had a chance to test it super thoroughly yet, but it works on my machines :tm:. Feel free to file an issue if it doesn't on yours :)
@HoldYourWaffle Would vite require to listen on TCP while I'd use your plugin?
@eirnym The IPC server is essentially a barebones proxy that forwards connections to Vite's TCP port. I've now clarified this in the README :)
Is there a reason why you can't have Vite listen on a TCP port at all?
UDS is not IPC first of all. Named pipe is. And windows has their UDS implementation as well.
The reason I'd like to have native UDS support without port forwarding is TCP listening port pollution. Especially on * address.
If I need just a proxy, I'll use a binary app written in Rust or Go, not in JavaScript. It will be faster and consume less resources and more reliable.
Why do you think UDS is not IPC? The man page specifically describes them as: "sockets for local interprocess communication". I'd love to use those on Windows too, but Node doesn't support that yet.
I did initially use socat, but integrating that nicely, especially on Windows, was much more painful than adding a line to plugins.
I'm not a JavaScript fan either, but the performance difference is irrelevant in a dev environment. Vite's TCP server is also JavaScript, that'll be the bottleneck long before a barebones stream piping proxy. If you're doing something extreme enough for it to matter then I'd love to see it.
Port pollution is an interesting point, but I don't see how that would cause issues in a dev environment either. Are you running a Vite server in production?
I refer to POSIX IPC. In your definition any communication between processes is IPC.
I don't support idea to publish on 0.0.0.0 by default and same ports are used in most development tools.
Referring to my local setup, I have local (::1/127.1) HTTP (Nginx) & DNS (Knot) server to support local development tools on a domain of my choice. This emulates production environment, but having all development tools. Thus I don't need to configure and remember all TCP ports I've used for all tools, and I don't need to reconfigure nginx server. Additionally, UDS is way faster (up to 30%) than TCP.
Configuration specific, let's take example.com as an example domain for development. I configured Knot to serve zone to resolve to ::1 and in nginx domain set up as reverse proxy to UDS socket in form of /common/path/domain.example.com. Cheap and easy.
I suppose UDS is defined in a different section of the POSIX spec, but I don't see how that distinction is relevant. The IPC section of POSIX isn't the definitive authority on what is and isn't IPC, it's just an abbreviation for inter-process communication. In any reasonable context that includes UDS, which is why most sources (including POSIX and both versions of the man page) describe UDS as IPC. Windows's named pipes aren't POSIX-compliant at all, but that doesn't make them less functional for communicating between processes.
Your setup sounds interesting, but I don't see how the pollution from using a proxy instead of native support would cause actual issues. Just add serveIPC({ path: "/common/path/domain.example.com" }) to your plugins, possibly fiddle with permissions and nginx should be able to connect. Vite will automatically pick an available port, so no need to think about that, nor does it publish on 0.0.0.0 by default.
Again, if you run into performance issues I'd love to see it.
For me it's not about performance but keeping things neatly organized in a containerized environment. e.g. I'm working on an application which has a backend and frontend part which are all started via a Procfile. The backend is a uvicorn server which creates a backend/uvicorn.sock. The frontend however opens port 3000.. I start a single Caddy server which acts as reverse proxy to those services which are now served from the same IP and port.
For the Time being I have this in my devcontainer.json so it doesn't create the annoying popups every time I start the application:
{
"...": "...",
"customizations": {
"vscode": {
"settings": {
"remote.portsAttributes": {
"3000": {
"label": "Frontend",
"onAutoForward": "ignore"
},
"4440-4442": {
"label": "Frontend HMR",
"onAutoForward": "silent"
},
"8000": {
"label": "Caddy",
"onAutoForward": "notify"
}
}
}
}
}
}
This is how my Caddyfile looks like:
{
http_port 8000
auto_https off
admin off
}
http://localhost, http://127.0.0.1 {
route {
@backend path /api /api/* /admin /admin/* /docs /docs/* /redoc /redoc/* /openapi.json
handle @backend {
reverse_proxy unix/backend/uvicorn.sock
}
handle {
reverse_proxy http://127.0.0.1:3000
}
}
}
It works, but proper UDS support would allow me to get rid of that hack in the devcontainer.json and make things a lot neater.
btw. it would be great if there was a way to expose the HMR ports the same way and override the URL so the dev server can run behind a reverse proxy and not expose any ports directly.
@HoldYourWaffle
PS (Moved to the top): Don't get me wrong, your plugin is a good workaround for lack of UDS support in Vite. I need a solution, not workaround.
IPC
In last years, many terms like IPC and API are used way broader. TCP is also a form of IPC, and any filesystem is also a form of IPC. and command line interface is API :D
Named pipes on Windows are may be not strictly POSIX IPC compliant, but they are too similar for Cygwin/MSYS/MSYS2 to actually easy wrap them around in POSIX IPC APIs.
While UDS on Windows works completely differently than on *BSD/macOS/Linux.
Again, if you run into performance issues I'd love to see it.
Your proposition is to add an additional layer of software is worse performance wise as Nginx needs to connect to socket, your plugin needs to process it, then your plugin needs to connect to Vite server via TCP and then transport it back. It more than doubles the cost per each request.
how the pollution from using a proxy instead of native support would cause actual issues
"random port" means I can't control it, it even worse than I have to specify it. Also it means I can't control on which IP I'd like to listen e.g. 127.0.0.2 or any other.
Inability to control, or having to much to control. I have plenty of services I test together before deployment, and one more port even random is worse. Additionally, using UDS I can control who and how can access the socket.
PPS: What your plugin itself lacking:
- Anything in CI/CD pipeline.
- Automatic updates using renovatebot or dependabot.
- More or less frequent updates for dependencies.
- Specification, which NodeJS version, package manager you're using.
- Information if is supports
denoandbun, preferably test and support.
Thanks for the PR and for taking the time to work on this. After discussion, we've decided not to move forward with this feature: https://github.com/vitejs/vite/issues/674#issuecomment-3355930300 We really appreciate the effort, even though we can't include it this time.
