Skip to content
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

Open
wants to merge 16 commits into
base: main
Choose a base branch
from

Conversation

Mastercuber
Copy link
Contributor

πŸ”— Linked issue

Closes #1

❓ Type of change

  • πŸ“– Documentation (updates to the documentation, readme, or JSdoc annotations)
  • 🐞 Bug fix (a non-breaking change that fixes an issue)
  • πŸ‘Œ Enhancement (improving an existing functionality like performance)
  • ✨ New feature (a non-breaking change that adds functionality)
  • 🧹 Chore (updates to the build process or auxiliary tools and libraries)
  • ⚠️ Breaking change (fix or feature that would cause existing functionality to 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 with Ctrl + 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 starting listhen 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

  • I have linked an issue or discussion.
  • I have updated the documentation accordingly.

@codecov
Copy link

codecov bot commented Aug 14, 2023

Codecov Report

Attention: Patch coverage is 59.25926% with 22 lines in your changes are missing coverage. Please review.

Project coverage is 50.57%. Comparing base (d115045) to head (0b06e49).
Report is 14 commits behind head on main.

Files Patch % Lines
src/listen.ts 64.51% 11 Missing ⚠️
src/cli.ts 0.00% 6 Missing ⚠️
src/_utils.ts 61.53% 5 Missing ⚠️
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.
πŸ“’ Have feedback on the report? Share it here.

src/cli.ts Outdated Show resolved Hide resolved
src/listen.ts Outdated Show resolved Hide resolved
src/listen.ts Outdated Show resolved Hide resolved
src/listen.ts Outdated Show resolved Hide resolved
@Mastercuber Mastercuber marked this pull request as draft August 14, 2023 17:24
@Mastercuber Mastercuber marked this pull request as ready for review August 14, 2023 18:34
README.md Outdated Show resolved Hide resolved
@Mastercuber
Copy link
Contributor Author

Mastercuber commented Aug 14, 2023

Thanks for your review BTW!

@Mastercuber Mastercuber force-pushed the ipc-listhen branch 2 times, most recently from 25a6b98 to 1148009 Compare August 16, 2023 19:54
@Mastercuber
Copy link
Contributor Author

Mastercuber commented Aug 16, 2023

@pi0
After a bit of refactoring, this PR looks much cleaner now.

Adding the signals traps is separated into #108 and an issue #107 was created for it.

The getURLs function now uses getURL also for sockets and just returns earlier.

Assertions used in both tests (http and https version) are extracted into functions.

Also the docs looks a bit cleaner now. With --ipc [name] and Default: false [listhen] it should be quickly possible to understand what is meant with it.

@Mastercuber Mastercuber force-pushed the ipc-listhen branch 6 times, most recently from c86ad62 to 93483dc Compare August 20, 2023 04:00
@pi0
Copy link
Member

pi0 commented Sep 8, 2023

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!

@Mastercuber
Copy link
Contributor Author

Mastercuber commented Sep 9, 2023

Indeed the generator wasn't necessary for passing the args.. I somehow have overseen the possibility to pass an object to server.listen.

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 \\?\pipe\<pipe-name> and are therefore no actual system paths.

Also have a nice weekend πŸ–οΈ

@Mastercuber Mastercuber force-pushed the ipc-listhen branch 3 times, most recently from 93aeffc to 6675c02 Compare September 18, 2023 20:35
Copy link

@Cheaterman Cheaterman left a 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`);

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!

Copy link
Contributor Author

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.

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 ?

Copy link
Contributor Author

@Mastercuber Mastercuber Oct 12, 2023

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.

Copy link

@Cheaterman Cheaterman Oct 16, 2023

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.

Copy link
Contributor Author

@Mastercuber Mastercuber Oct 16, 2023

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

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 :-)

@Cheaterman
Copy link

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support Unix Socket
3 participants