Gathering detailed insights and metrics for wait-port
Gathering detailed insights and metrics for wait-port
Gathering detailed insights and metrics for wait-port
Gathering detailed insights and metrics for wait-port
tcp-port-used
A simple Node.js module to check if a TCP port is already bound.
wait-on
wait-on is a cross platform command line utility and Node.js API which will wait for files, ports, sockets, and http(s) resources to become available
is-port-reachable
Check if a local or remote port is reachable
throttleit
Throttle a function to limit its execution rate
Simple binary to wait for a port to open. Useful for docker-compose and general server side activities.
npm install wait-port
Module System
Min. Node Version
Typescript Support
Node Version
NPM Version
334 Stars
162 Commits
18 Forks
4 Watching
16 Branches
12 Contributors
Updated on 27 Nov 2024
JavaScript (98.79%)
Makefile (1.21%)
Cumulative downloads
Total Downloads
Last day
7.5%
470,465
Compared to previous day
Last week
4.8%
2,397,135
Compared to previous week
Last month
10.5%
9,736,278
Compared to previous month
Last year
129%
78,449,491
Compared to previous year
Simple binary to wait for a port to open. Useful when writing scripts which need to wait for a server to be available.
docker-compose
commands which wait for servers to startInstall globally with npm
:
$ npm install -g wait-port
If installing locally, run the binary from the local node modules binary folder:
$ npm install wait-port
wait-port@0.1.3
$ ./node_modules/.bin/wait-port 8080
Waiting for localhost:8080.....
Connected!
Ideally, Node LTS should be used however this package is tested successfully with Node.js 10 and upwards.
Please avoid using version 0.2.13 - this incorrectly included a breaking change. Use 0.2.14 if you need compatibility with Node 8, or 0.3.0 or upwards otherwise.
To wait indefinitely for a port to open, just use:
1$ wait-port localhost:3000
To wait for a port to open, but limit to a certain timeout, use:
1$ wait-port -t 10000 localhost:3000
To wait for an HTTP endpoint to respond with a 200 class status code, include the http://
protocol:
1$ wait-port http://:3000/healthcheck
The following parameters are accepted:
Parameter | Usage |
---|---|
<target> | Required. The target to test for. Can be just a port, a colon and port (as one would use with httpie or host and port. Examples: 8080 , :3000 , 127.0.0.1:443 . |
--output, -o | Optional. Output style to use. Can be dots (default) or silent (no output). |
--timeout, -t | Optional. Timeout (in milliseconds). |
--wait-for-dns | Optional. Do not error if the response is ENOTFOUND , just keep on waiting (useful if you are waiting for a DNS record to also be created). |
The following error codes are returned:
Code | Meaning |
---|---|
0 | The specified port on the host is accepting connections. |
1 | A timeout occurred waiting for the port to open. |
2 | An unknown error occurred waiting for the port to open. The program cannot establish whether the port is open or not. |
3 | The address cannot be found (e.g. no DNS entry, or unresolvable). |
4 | The target (host and port) is invalid. |
You can use wait-port
programmatically:
1const waitPort = require('wait-port'); 2 3const params = { 4 host: 'google.com', 5 port: 443, 6}; 7 8waitPort(params) 9 .then(({ open, ipVersion }) => { 10 if (open) console.log(`The port is now open on IPv${ipVersion}!`); 11 else console.log('The port did not open before the timeout...'); 12 }) 13 .catch((err) => { 14 console.error(`An unknown error occured while waiting for the port: ${err}`); 15 });
The CLI is a very shallow wrapper around this function. The params
object takes the following parameters:
CLI Parameter | API Parameter | Notes |
---|---|---|
<target> | host | Optional. Defaults to localhost . |
<target> | port | Required. Port to wait for. |
--output | output | Optional. Defaults to dots . Output style to use. silent also accepted. |
--timeout, -t | timeout | Optional. Defaults to 0 . Timeout (in milliseconds). If 0 , then the operation will never timeout. |
--wait-for-dns | waitForDns | Optional. Defaults to false . |
This module uses:
Name | Usage |
---|---|
chalk | Terminal output styling. |
commander.js | Utility for building commandline apps. |
debug | Utility for debug output. |
mocha / nyc | Test runner / coverage. |
This module use debug
for debug output. Set DEBUG=wait-port
to see detailed diagnostic information:
1DEBUG=wait-port wait-for -t 10000 localhost:6234
This will also work for any code which uses the API.
Run unit tests with npm test
. Coverage is reported to artifacts/coverage
.
Debug unit tests with npm run debug
. Add a debugger
statement to the line you are interested in, and consider limiting scope with .only
.
Run tests continuously, watching source with npm run test:watch
.
Don't install the package to test the CLI. Instead, in the project folder run npm link
. Now go to whatever folder you want to use the module in and run npm link wait-port
. It will symlink the package and binary. See npm link
for more details.
Installing the CLI will install the manpage. The manpage is at ./man/wait-port.1
. After updating the page, test it with man ./man/wait-port.1
before publishing, as the format can be tricky to work with.
Kick out a new release with:
1npm run release 2git push --follow-tags 3npm publish
standard-version
is used to manage version numbers and the CHANGELOG.md
file.
CI/CD runs as a set of GitHub actions. There are two pipelines:
The timeout option for waitPort
is used terminate attempts to open the socket after a certain amount of time has passed. Please note that operations can take significantly longer than the timeout. For example:
1const promise = waitPort({ port: 9000, interval: 10000 }, 2000);
In this case, the socket will only attempt to connect every ten seconds. So on the first iteration, the timeout is not reached, then another iteration will be scheduled for after ten seconds, meaning the timeout will happen eight seconds later than one might expect.
The waitPort
promise may take up to interval
milliseconds greater than timeout
to resolve.
Thanks goes to these wonderful people (emoji key):
Kieran Barker 📖 |
This project follows the all-contributors specification. Contributions of any kind welcome!
No vulnerabilities found.
Reason
no dangerous workflow patterns detected
Reason
no binaries found in the repo
Reason
license file detected
Details
Reason
packaging workflow detected
Details
Reason
dependency not pinned by hash detected -- score normalized to 5
Details
Reason
Found 9/19 approved changesets -- score normalized to 4
Reason
8 existing vulnerabilities detected
Details
Reason
1 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
detected GitHub workflow tokens with excessive permissions
Details
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
security policy file not detected
Details
Reason
project is not fuzzed
Details
Reason
branch protection not enabled on development/release branches
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Score
Last Scanned on 2024-11-25
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More