Say you have a list of statically assigned ports associated with apps that may be running or not running.

If you start an app that is not already assigned, you want a new port, but one that is not already in your list.

So an option exclude would resolve this, which is much better than the workaround of manually specifying an array of include ports.

Any interest in accepting a PR to support passing in a preferred/default port?

Would you accept a PR that allowed usage like this:

getPort(minPort, maxPort).then()

If server.listen is used with a host, then get-port only returns the correct result if the same host value is provided.

// Some other project running on your machine:
server.listen(3000, 'localhost', cb);

This works, because we put in the host localhost, matching above:

// Your project:
await getPort({ port: 3000, host: 'localhost' }) 
// => Random port that is not bound to localhost, good!

However, when you don't know what host was used in the other project, or what host will be used in yours, you could be in trouble:

// Some other project running on your machine:
server.listen(3000, 'localhost', cb);

// Your project does one of these:

await getPort({ port: 3000 }) 
// => 3000...

await getPort({ port: 3000, host: '0.0.0.0' }) 
// => 3000...

await getPort({ port: 3000, host: '127.0.0.1' }) 
// => 3000...

await getPort({ port: 3000, host: '::' }) 
// => 3000...

If that 3000 port is then used later in your code with localhost, it will fail.

This might be a deficiency or feature in libev, or I'm not understanding how port binding works when the host is provided.

Workaround 1

Always use the same host when creating your server as used when running get-port. I'm finding that to not always be feasible.

Workaround 2

Math.max(
  await getPort({ port: 3000, host: 'localhost' }),
  await getPort({ port: 3000, host: '0.0.0.0' })
);
// => Will always be a random port, even if 3000 is available, 
// because `lockedPorts` ignores the `host`, so one of the two 
// getPort calls will think 3000 is already locked and return a random port.

Potential solution?

Maybe a possible workaround is to allow for passing in an array of hosts, or an option to check all localhost variants?

Hello.

I am experiencing a issue.
If I have a server running on e.g http://localhost:8080, the following code still assigns me port 8080 instead of a random port:

const getPort = require('get-port');

async function getRandomPort (preferredPort = 8080) {
  const port = await getPort({ port: preferredPort });
  return port;
}

getRandomPort(8080).then(port => console.log(port)); // 8080

Hello, I do encounter this issue :

node_modules/get-port/index.d.ts:1:29 - error TS2307: Cannot find module 'node:net' or its corresponding type declarations.

1 import {ListenOptions} from 'node:net';

Node version : v17.6.0

Thanks for your work on this package.

I'm using ava to set up multiple CDCT tests starting with this:

const test = require('ava')
const getPort = require('get-port')
const { Pact } = require('@pact-foundation/pact')

...

test.before('async() => {
  port = await getPort()
  console.log(`Setting up port ${port}`)

  provider = new Pact({
    port,
    ...
  })

  await provider.setup()
})

...

Works great, tests are running in parallel and different ports are used:

Setting up on port 64873
Setting up on port 64874

But Pact gives me a warning saying I'm using a port outside it's recommended range:

WARN: [email protected]/90509 on MBP.localdomain: Like a Boss, you used a port outside of the recommended range (1024 to 49151); I too like to live dangerously.

While it's just a warning, it's still not nice, so I change it to this:

test.before('async() => {
  port = await getPort({ port: getPort.makeRange(1024, 49151) })
  console.log(`Setting up port ${port}`)
  ...
})

But then both end up to be on the same port and my tests fail

Setting up on port 1024
Setting up on port 1024

Could the makeRange be randomized the same way as the default behaviour is?

Seems this package would go along well with https://github.com/bevry/hostenv for the port and hostname defaults

Not responding at all on windows

It seems there is a chance for race conditions.
In the time between getPort and the real use of the port (most probably another listen on the same port) it is possible that another process takes the port and it is no longer free.
At least this should be highlighted in the documentation.

Something like what I used in portman.

Description

I would like to request a function where when called the lockedPorts reset (both old and young)
or simply expose that object with exports so it can manually be cleared

This library either can't detect docker containers using ports or can't detect mongodb.

Ref: CImrie/mongomem#2 (comment)

When I run the below code in an Electron app

import getPort, { portNumbers } from 'get-port';
const port = (await getPort({ port: portNumbers(7092, 65535) })).toString();

I encountered the problem (0 , _getPort.portNumbers) is not a function

When I run await getPort() in an Electron app (dev) I get the following error:

Uncaught (in promise) TypeError: interval.unref is not a function

	if (interval === undefined) {
		interval = setInterval(() => {
			lockedPorts.old = lockedPorts.young;
			lockedPorts.young = new Set();
		}, releaseOldLockedPortsIntervalMs);

		interval.unref(); <----- HERE
	}

The author of this module may want to clarify in the README / API that get-port is just valid for getting a free TCP port.

Yes, this is Node.js and in Node.js all is about HTTP and stuff on top of HTTP. But UDP does also exist.

Thanks.

We noticed that get-port is defaulting to ipv6 for port resolution, which is giving false positives. i.e. given a default port, it comes back as available, where it is actually not available.

We will add more info to this issue shortly - Right now, we need an issue link for tracking purposes.

I'd like to get two or more free ports in the full range of ports with the assignment mechanism than getPort().

Now there is getPort.makeRange(1024, 65535) and calling .next() multiple times achieves a similar result but it's not exactly the same as getPort() because ports are assigned sequentially from the start argument.

I'd suggest a number option that that if passed changes the signature of the return value to an Array of port.

Is this + 1 logic correct?

If you run this snippet:

import { portNumbers } from 'get-port';

console.log([...portNumbers(65535, 65536)]);

You get the output

[ 65535, 65536 ]

The maximum port number should be 65,535 but the argument validation seems to allow the value 65536 to be returned.

If this is a bug I'd be happy to PR it.

Would be nice to see an option to provide a preferred range, rather than array of ports.

console.log(
  await getPort({port: 
    { 
      from: 4000,
      to: 5000
    }
  })
);

stroncium earned $30.00 by resolving this issue!

• Checkout the Issuehunt explorer to discover more funded issues.
• Need some help from other developers? Add your repositories on Issuehunt to raise funds.

I'm trying to use the server with multiple ports and dynamic response to get the port number within the range of port numbers
but they didn't support it on the server side.

get-port version->6.1.2

const getPort = require('get-port');
const {portNumbers} = require('portNumbers')
async ()=>{
    console.log(await getPort({port: portNumbers(5000, 6000)}));
}

I'm trying on

import getPort, {portNumbers} from 'get-port';

but the import module doesn't support on nodejs server, the only use of require method

Does anyone Have an idea?

I think it could be interesting to have the ability to pass an array of preferred ports instead of just one before get-port gives up and tries a random port.

Would this be possible?

Instead of checking if a file exists, we just try to open it.
So, instead of searching for a port, try to use the port and try another if it fails.

So, for example:

import express from 'express';
import {getValidatedPort} from 'get-port';
import pDefer from 'p-defer';

const app = express();

function listen(port) {
	const {promise, resolve, reject} = pDefer();

	app
		.listen(port, () => {
			app.off('error', reject);
			resolve();
		})
		.on('error', reject);

	return promise;
}

await getValidatedPort(listen);

What should the getValidatedPort function return? If we return the port that is used, we can't access the return value of the validation function and vice versa.

How should we check if the validator function approves an option? In the example, we check for a resolved or rejected promise but we could instead be checking for a boolean value.

I may need some guidance as to how to go about nailing down the cause. I'm using getPort in an ava test environment in conjunction with puppeteer and webpack. When using [email protected] everything works as expected. After updating to v5, I get multiple test files attempting to use the same port. My only shot-in-the-dark is that it's somehow related to the changes in v5 to the available port code.

Fwiw, my calls to getPort are relatively simple: getPort({ port: 55555 });

• Check 4723 in use:

lsof -n -i4TCP:4723

• Get free port by get-port:
  After 1 minute, i run below code.

const getPort = require('get-port');

(async () => {
  console.log('port 1 -> ', await getPort({ port: 4723 }));

  setTimeout(async () => {
    console.log('port 2 -> ', await getPort({ port: 4723 }));
  }, 2000);
})();

port 1 -> 4723
port 2 -> 50129

My PC is using 4723 port, but get-port still gives me 4723 port.

PS: I've tried some other library like portfinder and it works as expected.

I am using the default port feature but it does not seem to be catching the error on node 8.9 if the default port is taken. A listen EADDRINUSE error propagates.

See the feedback and initial work in #53 (If you want to work on this, please do a better job than that PR).

since getPort reserves a port and releases it to find an unused port number - trying to use that port number immediately afterwards may not work as *nix machines, which have a re-use timeout for the port to be available again.

This issue is for adding some documentation describing this behavior (if appropriate).

Related post:
https://unix.stackexchange.com/questions/17218/how-long-is-a-tcp-local-socket-address-that-has-been-bound-unavailable-after-clo

I use this library in my jest tests. Jest runs in parallel ~ 20 test files which use it. For such a use case the chance of race condition is not tiny, I think in my case it's 30%.

Is it possible to fix race condition?

Sometime It would be more convenient if the getPort supports synchronous mode.
For example, when I get the get the test config:

const _ = require('lodash');
const getPort = require('get-port');
const devConfig = require('./development.config');

exports.server = {
    port: getPort({ sync: true }),
};

exports.security = {
    jwtSecret: 'test_jwt_secret',
    passwordHashSaltRounds: 15,
};

exports.db = {
    dbName: 'coo-test',
};

module.exports = _.merge(devConfig, exports);

Hello,

I have an issue. The code is:

./index.js

const getPort = require('get-port');
const {spawn} = require('child_process');
const processExists = require('process-exists');
const delay = require('delay')
const fkill = require('fkill');

async function test() {
  const port = await getPort();
  console.log(port);
  const {pid} = spawn('node', ['fixture.js', port]);
  console.log(`Process exists with PID: ${pid}: ${await processExists(pid)}`);
  await fkill(pid);
  await delay(100);
  console.log(`Process exists with PID: ${pid}: ${await processExists(pid)}`);
	if(!await processExists(pid)) {
    const samePort = await getPort({port});
    console.log(samePort);
  } else {
    console.log('Process not killed');
  }
}

test();

./fixture.js

'use strict';
const http = require('http');

const server = http.createServer((request, response) => {
	response.end();
});

server.listen(process.argv.slice(2)[0]);

With version 4.2.0 the output is as expected

60328
Process exists with PID: 15767: true
Process exists with PID: 15767: false
60328

With ^5.0.0, however, the second time I'm requesting the port, it comes out 1 more than before:

60343
Process exists with PID: 15945: true
Process exists with PID: 15945: false
60344

Has anyone here encountered this issue or knows any way to solve it?

Given that get-port now returns a Promise, code that expects it to accept a callback will obviously not work.

I'd encourage you to use something like bluebird's asCallback(). this will make 1.x code still work against 2.x.

function getPort(callback) {
  return new Promise(resolve, reject) {
    // guts
  })
    .asCallback(callback);
});

not a huge issue, but this can cause confusion, because users who used to promisify get-port themselves will end up with a non-working function.

I tried using this module in an electron app, both in main and preload processes/scripts.

error:

Uncaught (in promise) Error: require() of ES Module C:\Users..\node_modules\get-port\index.js from C:\Users...\client\dist\preload\index.cjs not supported.
Instead change the require of index.js in C:\Users.....\client\dist\preload\index.cjs to a dynamic import() which is available in all CommonJS modules.
at __node_internal_captureLargerStackTrace (VM12 errors:464:5)
at new NodeError (VM12 errors:371:5)
at Object.Module._extensions..js (VM94 loader:1144:19)
at Module.load (VM94 loader:988:32)
at Module._load (VM94 loader:829:12)
at Function.c._load (VM110 asar_bundle:5:13331)
at Function.o._load (VM113 renderer_init:33:356)
at Module.require (VM94 loader:1012:19)
at require (VM93 helpers:102:18)
at VM115 C:\Users.....client\dist\preload\index.cjs:71:19

app template: git clone https://github.com/ch99q/vite-solid-electron.git

It's bug?
Becaust net.createServer host default is 'localhost'

Hi.
I use get-port in my jest test and it works perfectly since the 5.1.0 recent update.

Now my jest tests timeout and jest warns about some open handles from get-port.
Jest warn about this line https://github.com/sindresorhus/get-port/blob/master/index.js#L51 in particular.

My solution to make my test back to work is to downgrade get-port to 5.0.0.

Has anyone encountered this issue ?