Giters

socketio / engine.io-client

The engine used in the Socket.IO JavaScript client, which manages the low-level transports such as HTTP long-polling, WebSocket and WebTransport.

Home Page:https://socket.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Support `unref` method with option to `autoUnref`

KCErb opened this issue · comments

commented

I'm opening this issue to discuss a PR I put up three weeks ago. Perhaps some community discussion is more appropriate/likely here than there?

Is your feature request related to a problem? Please describe.

If the close API isn't used, then the transport layer leaves some things around that will prevent the event loop from exiting. This is problematic when you are creating a library that uses socket.io under the hood and your user fails to let you know explicitly they are done messaging (something I'd really like to support, especially since it can be hard to find out why your program isn't exiting and hard to communicate that it might be because they failed to call close).

Describe the solution you'd like

I can understand why sometimes the desired behavior would be precisely to keep the program from exiting since you're not done with your socket io client! But in my case, it'd be great to have an option that is analogous to the unref API provided for timers, sockets, servers, and the like in core Node (links in the PR: #652)

Also, I ended up bumping into a related issue in the socket.io-client package and found it could use the same option to get the same effect: socketio/socket.io-client#1442.

Describe alternatives you've considered
I described some alternatives in a related issue on the socket.io-client repo: socketio/socket.io-client#1446. Basically it seems my only options are to either spawn a child process or just accept that the close method needs to be called.

Additional context
#652

commented

@darrachequesne Is there a linked PR to upstream the https://github.com/mjwwit/node-XMLHttpRequest?
If not, do you mind if I take the liberty of opening one on your behalf (mjwwit/node-XMLHttpRequest#9)?

A quick glance suggests that this import mechanism causes a lot of transitive dependencies on socket.io to break in certain exotic environments, like codesandbox.io. (See codesandbox/codesandbox-client#4456 (comment))

commented

@shaoster sure, please do 👍