You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
importnetfrom'node:net'net.connect({ host, port })
Motivation
Performing a HEAD/GET request to the specified address is inefficient for a number of reasons:
It actually fetched the / resource on the given address. If the server needs to perform additional requests to serve /, this library would have to await those requests to finish before it resolves the HEAD/GET request. This is an unnecessary overhead.
The intention of wait-on is to resolve when the given address is available. The operability of the root route is irrelevant here, as long as the given address returns 200 OK in this case. You can verify that via net.connect() as well.
I raise this mostly because wait-on is a dependency in start-server-and-test, which is a widely used utility in E2E testing on the web. Performing a HEAD/GET request to / before the test run may have undesirable side effects, and this proposal aims to prevent that while keeping the familiar developer experience that's been around for years.
Benefits
Using net.connect() means support for protocols other than HTTP, which results in a more versatile library.
I believe you can stop caring about custom Agents altogether. Afaik, those are relevant only for HTTP requests, and you won't be making any with net.connect().
You can drop axios as a dependency.
Caution
I don't believe net.connect() will follow redirects so additional logic around it may be required to retain backward compatibility in wait-on.
I am happy with opening a pull request to implement this, but would kindly ask for your feedback and guidance first. Thanks.
The text was updated successfully, but these errors were encountered:
I also have a tiny proof of concept of using net.connect() to determine if the given address is running in https://github.com/kettanaito/until-connected. It's not a direct replacement with wait-on though, neither it has a goal to be one. Just an implementation reference if you are curious.
Hi! Thank you for creating this library?
May I suggest to migrate from making a HEAD/GET request to verifying if the connection to the given address can be established?
Current behavior
wait-on/lib/wait-on.js
Line 313 in 0b193cf
Proposed behavior
Motivation
Performing a HEAD/GET request to the specified address is inefficient for a number of reasons:
/
resource on the given address. If the server needs to perform additional requests to serve/
, this library would have to await those requests to finish before it resolves the HEAD/GET request. This is an unnecessary overhead.wait-on
is to resolve when the given address is available. The operability of the root route is irrelevant here, as long as the given address returns200 OK
in this case. You can verify that vianet.connect()
as well.I raise this mostly because
wait-on
is a dependency instart-server-and-test
, which is a widely used utility in E2E testing on the web. Performing a HEAD/GET request to/
before the test run may have undesirable side effects, and this proposal aims to prevent that while keeping the familiar developer experience that's been around for years.Benefits
net.connect()
means support for protocols other than HTTP, which results in a more versatile library.net.connect()
.axios
as a dependency.Caution
I don't believe
net.connect()
will follow redirects so additional logic around it may be required to retain backward compatibility inwait-on
.I am happy with opening a pull request to implement this, but would kindly ask for your feedback and guidance first. Thanks.
The text was updated successfully, but these errors were encountered: