-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: unix domain sockets and windows named pipe support #104
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #104 +/- ##
==========================================
+ Coverage 49.42% 50.57% +1.14%
==========================================
Files 17 17
Lines 1819 1835 +16
Branches 147 156 +9
==========================================
+ Hits 899 928 +29
+ Misses 915 902 -13
Partials 5 5 β View full report in Codecov by Sentry. |
Thanks for your review BTW! |
25a6b98
to
1148009
Compare
@pi0 Adding the signals traps is separated into #108 and an issue #107 was created for it. The Assertions used in both tests (http and https version) are extracted into functions. Also the docs looks a bit cleaner now. With |
c86ad62
to
93483dc
Compare
Thanks for putting efforts on this PR. It looks nice. I have added few refactors to simplify impl. Probably need more time to resolve merge conflicts and add little more fixes (tests are broken on macOS as it uses a random temp dir also we shall support absolute paths for socket that are outside of /tmp). Feel free to rebase or make any of those changes if had time to spend and have a nice weekend! |
e7ea74b
to
075378c
Compare
Indeed the generator wasn't necessary for passing the args.. I somehow have overseen the possibility to pass an object to Absolute paths on unixoid systems are also supported now and full pipe paths. Actually supporting full pipe paths seems unnecessary since they have to start with Also have a nice weekend ποΈ |
93aeffc
to
6675c02
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Support for relative socket paths would be nice, unless there's really a good reason to avoid that.
src/_utils.ts
Outdated
} | ||
return `\\\\?\\pipe\\${_name}`; | ||
} | ||
return isAbsolute(_name) ? _name : join(tmpdir(), `${_name}.socket`); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi and sorry to already comment on unmerged code but I really need this here so am doing all sorts of hacks to make it happen. Any reason you're forcing relative socket paths to /tmp/
? I use relative socket paths here and it breaks. Thanks in advance!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've developed this feature on a linux system and have no macOS device to test it on; that's the only reason, why relative paths wasn't correctly supported. Now relative paths should also be supported on macOS. This issues description should clarify.
The tmpdir()
function is returning a symbolic link on macOS, but with the realpathSync()
function it's possible to resolve the link to the actual absolute path.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi and thanks for your hard work! I'm sorry but I feel like there might have been a bit of a misunderstanding... my question was specifically about not forcing relative paths into /tmp
, instead relying on current working directory (as was my initial expectation). Is there any particular reason you force the socket into /tmp
? Or would it be OK to simply change L95 to return _name
instead of prepending /tmp
and adding .socket
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought of a path which will be the same on all OS's. The /tmp
directory (or better said the os.tmpdir()
function) seems to fit to this purpose. An absolute path can still be passed to through the listhen
arguments.
Just returning the path _name
. appending .socket
and using the working directory is another possibility, but you can also pass the working directory as an argument. The /tmp
directory is just used when no socket path is provided.
When this lines are commented out, the relative path utils test will fail.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe that's not what most people would expect :-) my use-case calls for ./frontend_run/nuxt.sock
; I can indeed use an absolute path by manually prefixing with $PWD
but there's not much I can do to remove the .socket
you're adding. Why wouldn't the path be the same on all OSes if you just let it through as-is? If I request frontend_run/nuxt.sock
I expect to get exactly that on UNIX ($PWD/frontend_run/nuxt.sock
) and something similar on Windows (%CD%\frontend_run\nuxt.sock
).
EDIT: Having read the tests, I'd argue they also need to be fixed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your objection!
I've changed the getSocketPath
function to pass the path through on unixoid systems.
Can't tell what was on my mind, while deciding to use the /tmp
directory instead of passing it through to let CWD be prepended by createServer
...
The tests are also fixed for this new behavior (and additionally the windows tests are separated in an extra suite)
.sock
now gets only appended to the path if no path is given => listhen.sock
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's really good now, thanks again for all your hard work :-)
6675c02
to
b8ef59f
Compare
Thanks again for all your hard work @Mastercuber, IMHO this PR looks really good now :-) would be great to merge it so we can have UNIX socket support for Nuxt devserver! |
β¦./ if not present
cbda020
to
50225e0
Compare
7db542a
to
0b06e49
Compare
π Linked issue
Closes #1
β Type of change
π Description
Here is yet another hopefully promising PR π
These PR adds support for listening on unix domain sockets or on windows named pipes. It adds the assignable CLI options, copies the full socket/pipe path to clipboard if wanted, prints the socket path and ignores all HTTPS options and also the
--open
option.While developing this PR, I recognized, that the
close()
function is neither called when the terminal is closed, nor when the process gets interrupted withCtrl + C
, so I added 3 signal traps to trigger the close call. With these traps the socket will get automatically cleaned up; without these traps - and without proper termination - the socket needs to be deleted manually before startinglisthen
again.2 tests are included. Unlike the h3 app test, the handle test is returning the same result for non existing paths. Is this expected behavior?
I've successfully executed the tests on Manjaro and on Windows 10.
π Checklist