concurrency.ts

Internal concurrency helpers — bounded Promise.all for the few sites where unbounded fan-out would risk resource exhaustion.

- MAX_FILE_CONCURRENCY — parallel readFile cap. Bounds FD pressure so projects with thousands of source files don't trip EMFILE against the typical 1024-FD ulimit. Used by files.globFiles and exports.discoverFromExports. - MAX_RESOLVE_CONCURRENCY — parallel resolver-call cap for session phase 2. Async resolvers (Vite/Rollup resolveId, user-supplied) get backpressure instead of a 20k+ task fan-out at once. Sync resolvers (TS default, no-deps stub) settle in microtasks regardless of the bound.

Same numerical value today, separately named so a future tuning pass can move them independently (FD pressure and resolver backpressure are unrelated limits that happen to coincide at this cap).

Declarations
#

3 declarations

view source

map_concurrent
#

concurrency.ts view source

<T, R>(items: readonly T[], concurrency: number, fn: (item: T, index: number) => Promise<R>): Promise<R[]>

Maps over items with a bounded number of in-flight promises, preserving input order.

Fail-fast: when fn rejects, the outer promise rejects with that error and idle workers stop pulling from the queue (already-in-flight fn calls run to completion — there's no AbortSignal plumbing). Subsequent rejections from in-flight calls are swallowed by Promise.all (only the first wins), so a misbehaving fn can't surface a second error after the function returns.

items

input array

type readonly T[]

concurrency

maximum number of concurrent operations

type number

fn

mapping function (receives item and index)

type (item: T, index: number) => Promise<R>

returns

Promise<R[]>

array of results in input order

MAX_FILE_CONCURRENCY
#

concurrency.ts view source

100

Internal concurrency helpers — bounded Promise.all for the few sites where unbounded fan-out would risk resource exhaustion.

- MAX_FILE_CONCURRENCY — parallel readFile cap. Bounds FD pressure so projects with thousands of source files don't trip EMFILE against the typical 1024-FD ulimit. Used by files.globFiles and exports.discoverFromExports. - MAX_RESOLVE_CONCURRENCY — parallel resolver-call cap for session phase 2. Async resolvers (Vite/Rollup resolveId, user-supplied) get backpressure instead of a 20k+ task fan-out at once. Sync resolvers (TS default, no-deps stub) settle in microtasks regardless of the bound.

Same numerical value today, separately named so a future tuning pass can move them independently (FD pressure and resolver backpressure are unrelated limits that happen to coincide at this cap).

MAX_RESOLVE_CONCURRENCY
#

Imported by
#