Idea — Use runtime-provided Socket API, if available

[irvinebroque]

A thought — would this have the highest impact if implemented as a polyfill?

Right now, this implementation assumes a Node.js environment, and wraps node:net and node:tls. It is effectively "an implementation of the connect() API that works in Node.js".

Library maintainers who need their library to work across runtimes would benefit most from a polyfill, where, if connect() is available, it is used directly, and runtime-specific APIs are never imported. That way, maintainers could just pull in this polyfill, and trust that it'd work across both Node.js and other runtimes that already provide the sockets API natively.

I can clean this up, and handle moving the Node.js imports to be conditional (to ensure that this can run in non-Node.js environments) — but I first wanted to submit the idea to get on the same page. Could also extend this to have logic that covered checking if you're in a Vercel Edge Functions environment, or any other runtime that makes the sockets available directly.

Thoughts? cc @jasnell — thinking back to the fetch() API — being able to pull in a polyfill that'd work across environments seemed at the time to me like it really helped libraries start adopting it, even as it took time to become available everywhere. But maybe there are dragons and downsides I'm not seeing of taking this approach :)

[irvinebroque]

(could alternatively see keeping this as the "pure" Node.js implementation, and publishing a separate package that is explicitly a polyfill)

[dom96]

(could alternatively see keeping this as the "pure" Node.js implementation, and publishing a separate package that is explicitly a polyfill)

I like this idea, it sounds like it would be the cleaner way to go.

[Ethan-Arrowood]

I like the idea of an explicit polyfill package

[sntran]

I also implemented an implementation for Deno. Would be nice to be able collect all these implementations into one polyfill package.