What types does the main pLimit function expect for its concurrency argument?

The pLimit function accepts concurrency as either a number or an Options object, per its type signature:

export default function pLimit(concurrency: number | Options): LimitFunction;

[index.d.ts:L89-L90]

The Options type requires a concurrency property (a number, minimum 1) and optionally a rejectOnClear boolean:

export type Options = {
	readonly concurrency: number;
	readonly rejectOnClear?: boolean;
};

[index.d.ts:L91-L106]

At runtime, in the JS implementation, if concurrency is passed as an object, it's destructured to pull out concurrency and rejectOnClear (defaulting the latter to false):

if (typeof concurrency === 'object') {
	({concurrency, rejectOnClear = false} = concurrency);
}

[index.js:L6-L8]

The resulting concurrency value is then validated by validateConcurrency, which enforces that it must be either a positive integer or Number.POSITIVE_INFINITY — anything else (e.g. 0, negative numbers, non-integers like 1.2, undefined, booleans, or an empty object without a concurrency key) throws a TypeError:

function validateConcurrency(concurrency) {
	if (!((Number.isInteger(concurrency) || concurrency === Number.POSITIVE_INFINITY) && concurrency > 0)) {
		throw new TypeError('Expected `concurrency` to be a number from 1 and up');
	}
}

[index.js:L123-L128]

This validation behavior is confirmed in the test suite, which checks that pLimit(0), pLimit(-1), pLimit(1.2), pLimit(undefined), pLimit(true), pLimit({}), and pLimit({concurrency: 0}) all throw [test.js:L275-L303].

Additionally, rejectOnClear (when provided via the options object) is validated separately as a boolean:

if (typeof rejectOnClear !== 'boolean') {
	throw new TypeError('Expected `rejectOnClear` to be a boolean');
}

[index.js:L10-L12]

FOLLOW_UPS:

• How does limit.concurrency setter change queue processing?
• What does clearQueue() do with rejectOnClear enabled?
• How does the internal Queue class work in p-limit?