Use next available port instead of hardcoded as default when using `run` command
Running webxdc-dev run ... without using the --port flag results in the following error on my machine:
Error: listen EADDRINUSE: address already in use :::7000
Looks like this comment didn't age too well 😅 :
https://github.com/webxdc/webxdc-dev/blob/0b9fafed598f0e8cb7a6d20e40991d40187a5bdd/CHANGELOG.md#L295
Instead of a hardcoded port as the default, I would suggest using a module like https://github.com/sindresorhus/get-port to get the next available port if the preferred one isn't available.
@achou11 Any alternative to get-port available that does the same? This is opening a can of worms because $reasons.
$reasons
So TypeScript is configured to build commonjs:
Which results in the following built javascript:
I.e. using import in the TypeScript really result in doing the good ole require. Buuuuut get-port doesn't allow you to do that since it's a es6 module. So it would be easier if there was a good ole require module doing the same.
Yes, I have tried changing tsconfig-backend.json as well to produce something else than commonjs but then you run into other issues. It just doesn't stop :)
Looks like @davidmarkclements has done a version of it here https://github.com/davidmarkclements/get-port/blob/master/index.js
EDIT: Nope, this isn't the code. It does something else and the repository is even gone from github :/
@ralphtheninja if trying to get a closest match to a preferred port isn't a requirement, pretty sure you can let Express use Node's default behavior of choosing a random available port by specifying 0.
Docs from Express v4 listen() method:
If port is omitted or is 0, the operating system will assign an arbitrary unused port, which is useful for cases like automated tasks (tests, etc.).
@ralphtheninja if trying to get a closest match to a preferred port isn't a requirement, pretty sure you can let Express use Node's default behavior of choosing a random available port by specifying
0.
I found detect-port and it works really well, see #69