Currently, the intended scope of the package is only to wait for http servers for tests.
It is not anticipated to forward a port to a remote host to execute a command against it.
For example, a postgres database may not expose its port directly to the internet, but one can use ssh to forward the port onto localhost.
PGPASSWORD=sEcr3T npx start-server-and-test 'ssh -TL 5432:127.0.0.1:5432 my-server.com' tcp:5432 'psql -h localhost --user postgres -c "select * from foo;"'
This might already work with start-server-and-test apparently because of the ability of the wait-on package to wait for an open tcp port instead of for a http response.
There are quite many tools that offer some kind of port forwarding (for example kubectl, ssh, google cloudsql proxy, aws system manager) and it is common to have to wait for e.g. a database to be available in tests or to execute database migration scripts against it in deploy job.
The current name of the package start-server-and-test does not seem well suited to this more general use case, but the functionality is the needed one. To support this use case, one would have to
- Expand the README.md a bit with an added example of this use case
- Change some
console.log to console.error to not contaminate the stdout stream of the executed command to allow piping it into other tools.
What do you think?
Currently, the intended scope of the package is only to wait for http servers for tests.
It is not anticipated to forward a port to a remote host to execute a command against it.
For example, a postgres database may not expose its port directly to the internet, but one can use ssh to forward the port onto localhost.
This might already work with
start-server-and-testapparently because of the ability of thewait-onpackage to wait for an open tcp port instead of for a http response.There are quite many tools that offer some kind of port forwarding (for example kubectl, ssh, google cloudsql proxy, aws system manager) and it is common to have to wait for e.g. a database to be available in tests or to execute database migration scripts against it in deploy job.
The current name of the package
start-server-and-testdoes not seem well suited to this more general use case, but the functionality is the needed one. To support this use case, one would have toconsole.logtoconsole.errorto not contaminate the stdout stream of the executed command to allow piping it into other tools.What do you think?