sindresorhus / p-limit

Run multiple promise-returning & async functions with limited concurrency

p-limit

Run multiple promise-returning & async functions with limited concurrency

Works in Node.js and browsers.

Install

npm install p-limit

Usage

import pLimit from 'p-limit';

const limit = pLimit(1);

const input = [
	limit(() => fetchSomething('foo')),
	limit(() => fetchSomething('bar')),
	limit(() => doSomething())
];

// Only one promise is run at once
const result = await Promise.all(input);
console.log(result);

API

pLimit(concurrency)

Returns a limit function.

concurrency

Type: number
Minimum: 1
Default: Infinity

Concurrency limit.

limit(fn, ...args)

Returns the promise returned by calling fn(...args).

fn

Type: Function

Promise-returning/async function.

args

Any arguments to pass through to fn.

Support for passing arguments on to the fn is provided in order to be able to avoid creating unnecessary closures. You probably don't need this optimization unless you're pushing a lot of functions.

limit.activeCount

The number of promises that are currently running.

limit.pendingCount

The number of promises that are waiting to run (i.e. their internal fn was not called yet).

limit.clearQueue()

Discard pending promises that are waiting to run.

This might be useful if you want to teardown the queue at the end of your program's lifecycle or discard any function calls referencing an intermediary state of your app.

Note: This does not cancel promises that are already running.

limit.concurrency

Get or set the concurrency limit.

FAQ

How is this different from the p-queue package?

This package is only about limiting the number of concurrent executions, while p-queue is a fully featured queue implementation with lots of different options, introspection, and ability to pause the queue.

Related

• p-throttle - Throttle promise-returning & async functions
• p-debounce - Debounce promise-returning & async functions
• p-all - Run promise-returning & async functions concurrently with optional limited concurrency
• More…

p-limit's Issues

Feature request: key based p-limit.

This should probably be implemented in a separated repository. I am looking for a package that will support something like:

const pKeyLimit = require('p-key-limit');
const limiter = pKeyLimit(1); // concurrency is 1
limit('k1', () => taskA()).then(result => console.log(`Task A Done: ${result}`));
limit('k2', () => taskB()).then(result => console.log(`Task B Done: ${result}`)); // different key (k2) - will run in parallel to taskA
limit('k1', () => taskC()).then(result => console.log(`Task C Done: ${result}`)); // same key (k1) - will start executing after taskA has finished (recall that concurrency is 1).

Obviously, this could be implemented by maintaining a Map of keys to p-limits. However, there should be some way to clean the map from p-limits that have finished (maybe by wrapping the function that is passed to the internal p-limit).

I will be happy to hear if something like that was already implemented!

pLimit giving me a list of undefined promises

        const maxParallelRequests = 1;
		const limit = pLimit(maxParallelRequests);

		// Use the map method to create an array of promises for each call to GetData
		const promises = items.map(item => {
			limit(() => this.getData(item))
		});

When I log promises I get an array of 60 undefined items.

What am I doing wrong here?

item is defined inside the map function.

should not ignore errors.

Promise.all rejects if any given promise is rejected. I think p-limit should follow this standard behavior.

[Feature Request] `require("p-limit")` backward compatibility

p-limit 4 dropped commonjs style import support. Though one very practical issue we encounter was that even if "our" project uses ESM, since there are still many libraries we use executes require("p-limit"), so we had no choice but forced to use p-limit 3.

I understand that ESM is the best practice and the future, but practically, the third party require("p-limit") issue will prevent us (and many others) from using p-limit 4 for many years, if not ever.

UnhandledPromiseRejectionWarning: /node_modules/p-limit/index.js:29

try {
  await result;
} catch {}

Can we throw an error here or just invoke next() in the catch? getting an UnhandledPromiseRejectionWarning during a build.

What's the difference between your implementation and this KISS implementation?

What's the difference between your implementation and this KISS implementation?

const allLimit = async (promises, { concurrency = 0 } = {}) => {
  if (concurrency < 1) {
    return (await Promise.all(promises.map((p) => p())));
  }
  let result = [];
  for (const promisesChunk of chunk(promises, concurrency)) {
    const t = await Promise.all(promisesChunk.map((p) => p()));
    result = result.concat(t);
  }
  return result;
};

Do we really need yocto-queue?

Same data after limit amount.

for (data of pinfo) {
    for (linkIndex in data.links) {
        promises.push(
            limit(async () => {
                const fileName = getFileName(data.category, data.subCategory, linkIndex + '.html');
                console.log(fileName);
                try {
                    readFileSync(fileName);
                } catch (e) {
                    const url = data.links[linkIndex].replace(/^https:\/\/detail\./i, 'https://m.');
                    console.log('Grabbing ' + url);
                    const d = await request(url);
                    writeFileSync(fileName, d);
                }
            }, data.category, data.subCategory, linkIndex)
        );
    }
}

If i set limit to say 20 then data.category, data.subCategory, linkIndex start to become same for other promises so weird :(

New feature: concurrency limiting pool/provider

The following is kind of a lazy way to do a PR--sorry.

Anyway, the following class acts something like an object/resource pool. However, instead of generating multiple instances of the underlying object, there's a single copy of the object but it only gets released while the number of in-flight async function calls remains below the concurrency limit:

import pLimit, {LimitFunction} from 'p-limit';

export class PLimitProvider<TContext> {
  private readonly _pLimit: LimitFunction;
  private readonly _pLimitedContext: TContext;

  constructor(pLimitedContext: TContext, concurrencyLimit: number) {
    this._pLimitedContext = pLimitedContext;
    this._pLimit = pLimit(concurrencyLimit);
  }

  public run<TResult>(f: (context: TContext) => TResult | Promise<TResult>): Promise<TResult> {
    return this._pLimit(() => f(this._pLimitedContext));
  }
}

Example usage:

import {S3} from '@aws-sdk/client-s3';

function fetchFromSomeBucket(s3Provider: PLimitProvider<S3>, fileKey: string) {
  return s3Provider.run(client => client.getObject({
    Bucket: 'someBucket',
    Key: fileKey
  }));
}

const fetchWithExpandedKey = (s3Provider: PLimitProvider<S3>, fileKey: string) =>
  fetchFromSomeBucket(s3Provider, `/expanded/${fileKey}`);

async function main() {
  const maxS3Concurrency = 2;
  const s3ClientProvider = new PLimitProvider(new S3({}), maxS3Concurrency);
  
  const getFilePromise1 = fetchFromSomeBucket(s3ClientProvider, 'someFileKey1');
  const getFilePromise2 = fetchWithExpandedKey(s3ClientProvider, 'someFileKey2');

  // Has to wait until one of the preceding completes
  const getFilePromise3 = fetchFromSomeBucket(s3ClientProvider, 'someFileKey3');

  await Promise.all([getFilePromise1, getFilePromise2, getFilePromise3]);
}

This makes it easier to pass the LimitFunction around with the client for a given service and make sure any calls made with the client are wrapped with the LimitFunction.

AbortController throws inside p-limit

Describe the bug

I created a simple basic application which uses node-fetch to send some HTTP(S)-Requests and uses p-limit to reduce the amount of requests send at the same time. The problem is when the node-fetch requests get aborted by an AbortController they throw inside p-limit so I can't handle the AbortError.

Reproduction

I'm providing a stripdown version of the application which only contains the parts necessary to trigger the bug.

Here is the stripdown version with p-limit

import fetch, { FormData, File } from 'node-fetch';
import pLimit from 'p-limit';

async function sendRequest(abortController) {
    try {
        const formData = new FormData();
        formData.set('file', new File(['Some text here..'], 'a.txt'));

        await fetch('https://example.com', {
            method: 'POST',
            body: formData,
            signal: abortController.signal,
        });
    } catch {
        console.error("Something wen't wrong doing request.");
    }
}

(async () => {
    const limit = pLimit(10);
    const abortController = new AbortController();

    const jobs = [];
    for (let i = 0; i < 10; i++) {
        jobs.push(limit(() => sendRequest(abortController)));
    }

    abortController.abort();

    await Promise.allSettled(jobs);
    console.log('Done sending all requests.');
})();

which generates the following output:

...
Something wen't wrong doing request.
Something wen't wrong doing request.
Done sending all requests.
node:events:515
      throw er; // Unhandled 'error' event
      ^

AbortError: The operation was aborted.

Here is the stripdown version without p-limit

import fetch, { FormData, File } from 'node-fetch';

async function sendRequest(abortController) {
    try {
        const formData = new FormData();
        formData.set('file', new File(['Some text here..'], 'a.txt'));

        await fetch('https://example.com', {
            method: 'POST',
            body: formData,
            signal: abortController.signal,
        });
    } catch {
        console.error("Something wen't wrong doing request.");
    }
}

(async () => {
    const abortController = new AbortController();

    const jobs = [];
    for (let i = 0; i < 10; i++) {
        jobs.push(sendRequest(abortController));
    }

    abortController.abort();

    await Promise.allSettled(jobs);
    console.log('Done sending all requests.');
})();

which generates the following output:

...
Something wen't wrong doing request.
Something wen't wrong doing request.
Done sending all requests.

Severity

blocking all usage of p-limit - as I can't abort requests without crashing the entire application.

Best regards
UnlimitedBytes

The type definition in v3 is broken

The default export was removed in this commit: b35faf5#diff-168726dbe96b3ce427e7fedce31bb0bcL65

However, the .d.ts file still suggests there is a default export

Unexpected token

node: v16.3.0

Error: code: 'ERR_REQUIRE_ESM' in TS

Hi, I have the following code

import pLimit from 'p-limit' const limit = pLimit(8)

And I receive an error in my console:
var _pLimit = _interopRequireDefault(require("p-limit"));

Need to pass functions being called in the limit function?

Considering the following code:

const myFunc = (var1) => {...}

const promises = []
promises.push(limit(async (var1) => {
  myFunc(var1);
}, passedVar1)
await Promises.all(promises)

Should I be passing myFunc as part of the args when passing it to the limit generator? Or is the outside reference ok?

typescript Module not found: Error: Can't resolve '#async_hooks' in 'F:\workproject\management-service\node_modules\p-limit'

ERROR in ./node_modules/p-limit/index.js 2:0-43
Module not found: Error: Can't resolve '#async_hooks' in 'F:\workproject\management-service\node_modules\p-limit'
resolve '#async_hooks' in 'F:\workproject\management-service\node_modules\p-limit'
using description file: F:\workproject\management-service\node_modules\p-limit\package.json (relative path: .)
resolve as internal import
using imports field: async_hooks
Parsed request is a module
using description file: F:\workproject\management-service\node_modules\p-limit\package.json (relative path: .)
resolve as module
F:\workproject\management-service\node_modules\p-limit\node_modules doesn't exist or is not a directory
F:\workproject\management-service\node_modules\node_modules doesn't exist or is not a directory
looking for modules in F:\workproject\management-service\node_modules
single file module
using description file: F:\workproject\management-service\package.json (relative path: ./node_modules/async_hooks)
no extension
F:\workproject\management-service\node_modules\async_hooks doesn't exist
.tsx
F:\workproject\management-service\node_modules\async_hooks.tsx doesn't exist
.ts
F:\workproject\management-service\node_modules\async_hooks.ts doesn't exist
.js
F:\workproject\management-service\node_modules\async_hooks.js doesn't exist
F:\workproject\management-service\node_modules\async_hooks doesn't exist
F:\workproject\node_modules doesn't exist or is not a directory
F:\node_modules doesn't exist or is not a directory
@ ./src/main/nppv-report/app/query/NPPVMultipleDailyReportQuery.ts 20:34-52
@ ./src/main/nppv-report/NPPVReportModule.ts 20:39-90
@ ./src/main/main.ts 24:27-68
@ ./src/index.ts 7:15-37

webpack 5.89.0 compiled with 1 error in 16991 ms
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] build: eslint src --ext .ts && webpack
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] build script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR! C:\Users\Lenovo\AppData\Roaming\npm-cache_logs\2023-11-16T08_34_47_721Z-debug.log

es5 support for old browsers?

Package idea is awesome, but i have problem with browserify to es5. Is it official position to drop es5 support or PR will be accepted?

I could suggest 2 things on your choice:

1. Use es5 syntax (i would prefer this way, see no big reasons for es6 here)
2. Add browserify config to package.json:

   "browserify": {
     "transform": [
       [
         "babelify",
         {
           "presets": [
             "es2015"
           ]
         }
       ]
     ]
   },

I'm ready to prepare PR if allowed.

Error on try catch block

I'm trying to deploy a function to firebase, and looks like one of the packages I use, uses p-limit, and when trying to deploy the function, in the installation modules package the console gives me the following error:

Detailed stack trace: /srv/node_modules/p-limit/index.js:30
} catch {}

inspecting the p-limit code in my node_modules I see this in line 28

try { await result; } catch {}

there's an error in the catch expression, is missing the parenthesis after catch, catch(error) {}

Firebase functions uses node version 8

https://github.com/sindresorhus/p-limit/blob/master/index.js#L30

Unexpected token {

Registering Gruntfile tasks.
Loading "Gruntfile.js" tasks...ERROR

>> /home/travis/build/alaa/tesh/node_modules/terser-webpack-plugin/node_modules/p-limit/index.js:30
>>         } catch {}
>>                 ^
>> 
>> SyntaxError: Unexpected token {
>>   at createScript (vm.js:80:10)
>>   at Object.runInThisContext (vm.js:139:10)
>>   at Module._compile (module.js:617:28)
>>   at Object.Module._extensions..js (module.js:664:10)
>>   at Module.load (/home/travis/build/alaa/tesh/node_modules/coffeescript/lib/coffee-script/register.js:45:36)
>>   at tryModuleLoad (module.js:506:12)
>>   at Function.Module._load (module.js:498:3)
>>   at Module.require (module.js:597:17)
>>   at require (internal/module.js:11:18)
>>   at Object.<anonymous> (/home/travis/build/alaa/tesh/node_modules/terser-webpack-plugin/dist/index.js:26:38)
>>   at Module._compile (module.js:653:30)
>>   at Object.Module._extensions..js (module.js:664:10)
>>   at Module.load (/home/travis/build/alaa/tesh/node_modules/coffeescript/lib/coffee-script/register.js:45:36)
>>   at tryModuleLoad (module.js:506:12)
>>   at Function.Module._load (module.js:498:3)
>>   at Module.require (module.js:597:17)
>>   at require (internal/module.js:11:18)
>>   at Object.<anonymous> (/home/travis/build/alaa/tesh/node_modules/terser-webpack-plugin/dist/cjs.js:3:16)
>>   at Module._compile (module.js:653:30)
>>   at Object.Module._extensions..js (module.js:664:10)
>>   at Module.load (/home/travis/build/alaa/tesh/node_modules/coffeescript/lib/coffee-script/register.js:45:36)
>>   at tryModuleLoad (module.js:506:12)
>>   at Function.Module._load (module.js:498:3)
>>   at Module.require (module.js:597:17)
>>   at require (internal/module.js:11:18)
>>   at Object.<anonymous> (/home/travis/build/alaa/tesh/webpack.buildconfig.js:3:22)
>>   at Module._compile (module.js:653:30)
>>   at Object.Module._extensions..js (module.js:664:10)
>>   at Module.load (/home/travis/build/alaa/tesh/node_modules/coffeescript/lib/coffee-script/register.js:45:36)
>>   at tryModuleLoad (module.js:506:12)
>>   at Function.Module._load (module.js:498:3)
>>   at Module.require (module.js:597:17)
>>   at require (internal/module.js:11:18)
>>   at /home/travis/build/alaa/tesh/webpack.config.js:4:12
>>   at Object.<anonymous> (/home/travis/build/alaa/tesh/webpack.config.js:5:2)
>>   at Module._compile (module.js:653:30)
>>   at Object.Module._extensions..js (module.js:664:10)
>>   at Module.load (/home/travis/build/alaa/tesh/node_modules/coffeescript/lib/coffee-script/register.js:45:36)
>>   at tryModuleLoad (module.js:506:12)
>>   at Function.Module._load (module.js:498:3)
>>   at Module.require (module.js:597:17)
>>   at require (internal/module.js:11:18)
>>   at Object.module.exports (/home/travis/build/alaa/tesh/Gruntfile.js:9:25)
>>   at loadTask (/home/travis/build/alaa/tesh/node_modules/grunt/lib/grunt/task.js:315:10)
>>   at Task.task.init (/home/travis/build/alaa/tesh/node_modules/grunt/lib/grunt/task.js:434:5)
>>   at Object.grunt.tasks (/home/travis/build/alaa/tesh/node_modules/grunt/lib/grunt.js:111:8)
>>   at Liftoff.<anonymous> (/home/travis/.nvm/versions/node/v8.12.0/lib/node_modules/grunt-cli/bin/grunt:66:13)
>>   at Liftoff.execute (/home/travis/.nvm/versions/node/v8.12.0/lib/node_modules/grunt-cli/node_modules/liftoff/index.js:203:12)
>>   at module.exports (/home/travis/.nvm/versions/node/v8.12.0/lib/node_modules/grunt-cli/node_modules/flagged-respawn/index.js:51:3)
>>   at Liftoff.<anonymous> (/home/travis/.nvm/versions/node/v8.12.0/lib/node_modules/grunt-cli/node_modules/liftoff/index.js:195:5)
>>   at Liftoff.<anonymous> (/home/travis/.nvm/versions/node/v8.12.0/lib/node_modules/grunt-cli/node_modules/liftoff/index.js:170:7)
>>   at _combinedTickCallback (internal/process/next_tick.js:132:7)
>>   at process._tickCallback (internal/process/next_tick.js:181:9)

Try/catch block failing in Jenkins build

Environment

React app, bundled with Webpack, deployed with Jenkins. Using p-limit through terser-webpack-plugin.

Issue

Jenkins build fails with console output:

/path/to/repo/node_modules/terser-webpack-plugin/node_modules/p-limit/index.js:30
		} catch {}
		        ^

SyntaxError: Unexpected token {

Suggestion

I think it's expecting a condition to follow the catch keyword on index.js:30

Perhaps changing the following might work.

try {
  await result;
} catch {}

to

try {
  await result;
} catch (error) {}

Thanks! Please let me know if I can help further

Support lost for Node 16 / CommonJs

Hello,
I was running p-limit@3 and tried to upgrade to p-limit@4

Reproduce error

➜  test cat package.json 
{
  "dependencies": {
    "p-limit": "^4.0.0"
  }
}

My program is in Typescript and I'm compiling to use CommonJS native ("module": "commonjs", in my tsconfig)

➜  test cat index.js 
const pLimit = require("p-limit")

console.log(pLimit)

resulting to an error at runtime

➜  test node index.js 
/home/portal/test/index.js:1
const pLimit = require("p-limit")
               ^

Error [ERR_REQUIRE_ESM]: require() of ES Module /home/portal/test/node_modules/p-limit/index.js from /home/portal/test/index.js not supported.
Instead change the require of /home/portal/test/node_modules/p-limit/index.js in /home/portal/test/index.js to a dynamic import() which is available in all CommonJS modules.
    at Object.<anonymous> (/home/portal/test/index.js:1:16) {
  code: 'ERR_REQUIRE_ESM'
}

With 3.x

program is working

➜  test node .          
[Function: pLimit]

Is the support lost, or am I using the lib wrongly?

Should clearQueue() reject the pending promises?

Right now it leaves them hanging indefinitely. It seems like undesirable behavior, though I guess it ultimately depends on the use case.

It doesn't seem to finish all tasks if the queue is generated in a for loop

I'm using the p-limit for limit the concurrence for file writing (about 6k files). The code below works fine:

`
var writeFilePLimit = pLimit(100);
var writeFileQueue = [];

Object.keys(allData).forEach(data => {
  writeFileQueue.push(writeFilePLimit(async () => {
    await fs.promises.writeFile(path, JSON.stringify(data));
  }));
});

`

However, if I do

`
var writeFilePLimit = pLimit(100);
var writeFileQueue = [];

for (var data in allData) {
  writeFileQueue.push(writeFilePLimit(async () => {
    await fs.promises.writeFile(path, JSON.stringify(data));
  }));
}

`

then it will only execute 102 files writes (out of 6k files in total). And the 102 files seems to be the first 100 files and the last two files.

I'm not sure whether there is some difference between for loop and Array.forEach() resulted in this. Just want to post this here to see whether I did something wrong.

Thanks!

catch syntax error

when use the copy-webpack-plugin,the console show the error of catch syntax error , it's like forget the '(e)'

Why are there no parentheses after the catch statement

I don’t know if this is a new way of writing, but there will be an error without parentheses 😱

Increase required nodejs version to 10.3 or get rid of Optional Catch Binding

This line causes crash on nodejs < 10.3:

p-limit/index.js

Line 30 in b702cc1

} catch {}

This is "Optional Catch Binding" and is only supported in nodejs version 10.3 and higher, see https://node.green/#ES2019-misc-optional-catch-binding

catch err missing

Hi Can I submit a pull request for the index.js?

There is a catch {} on line 29 of index.js that should be

catch(err) {
                        reject(err)
                }

I was unable to use p-limit on one of our servers without changing the node-module

Package breaks IE11 unless built

Since IE11 doesn't support arrow functions or rest/spread, the existing package breaks projects that use it in IE11 if they don't build node_modules (a common pattern). This would be resolved if this package were built to target ES5. (Here's another package that ran into this separately.)

Recent change for concurrency is breaking change

Should we up the major version since it no longer can take in a string value for concurrency which may technically be a backwards incompatible change. I know my lib broke from "p-limit": "^2.2.0", which was automatically pulled in on the latest change.

"try catch {}" causing SyntaxError: Unexpected token { in node 8.11.3

Please guys, replace this expression in index.js:

	try { await result; } catch {}

for this one

           try { await result; }  catch (e) {}

It's causing problems in older node versions

Thanks!

p-queue vs p-limit

Hello,
I would like to understand the different use-cases for using p-queue vs p-limit.

I have a singleton class which fires http requests, it is triggered by different components across my app. I would like to limit the max requests in parallel, and both seems to fit my purpose (even though I find p-limit a nicer approach)

Propose `limit.with` API to streamline `map()` usage

Hello, I'd like to propose introducing a limit.with API to streamline the process of creating limited functions with Array.prototype.map()

Current API:

const limit = pLimit(5)

// With inline function
await Promise.all(
  items.map(item => limit(async () => {
    await process(item)
  }))
)

// With function declaration
async function processItem(item) {
  await process(item)
}

await Promise.all(
  items.map(item => limit(() => processItem(item)))
)

Proposed API:

const limit = pLimit(5)

// With inline function
await Promise.all(
  items.map(limit.with(async item => {
    await process(item)
  }))
)

// With function declaration
async function processItem(item) {
  await process(item)
}

await Promise.all(
  items.map(limit.with(processItem))
)

While the difference is subtle, the intention is to remove some boilerplate and improve readability. I put together a POC here and am happy to follow up with documentation, any API/naming/etc changes, and opening a PR

Vite requires packages to export package.json

This is the warning created by Vite:

[vite-plugin-svelte] The following packages did not export their `package.json` file so we could not check the "svelte" field. If you had difficulties importing svelte components from a package, then please contact the author and ask them to export the package.json file.
- p-limit
- yocto-queue

p-limit 2.2.0 can't be accessed by yarn

reproduce:
yarn install
yarn.lock

then throw error: 405 Method Not Allowed
when I using browser to visit the url:
https://registry.yarnpkg.com/p-limit/download/p-limit-2.2.0.tgz
Also, return 405 method not allowed.
any ideas?
Thanks

question: when is memory for each queued function garbage collected?

if you put 1000 functions into a queue, will the memory for each be managed along the way or will they all be garbage collected after all promises are resolved?

Does p-limit support Promise.allSettled?

According to https://www.npmjs.com/package/chunk-promise, p-limit does not support Promise.allSettled. Is that true?

Jest giving error - SyntaxError: Cannot use import statement outside a module

I am using -
[email protected]
[email protected]

npm v8.15.0
node v16.17.0

Jest error:

 FAIL  src/components/livelink/GenerateLiveLink/index.test.js
  ● Test suite failed to run

    Jest encountered an unexpected token

    Jest failed to parse a file. This happens e.g. when your code or its dependencies use non-standard JavaScript syntax, or when Jest is not configured to support such syntax.

    Out of the box Jest supports Babel, which will be used to transform your files into valid JS based on your Babel configuration.

    By default "node_modules" folder is ignored by transformers.

    Here's what you can do:
     • If you are trying to use ECMAScript Modules, see https://jestjs.io/docs/ecmascript-modules for how to enable it.
     • If you are trying to use TypeScript, see https://jestjs.io/docs/getting-started#using-typescript
     • To have some of your "node_modules" files transformed, you can specify a custom "transformIgnorePatterns" in your config.
     • If you need a custom transformation specify a "transform" option in your config.
     • If you simply want to mock your non-JS modules (e.g. binary assets) you can stub them out with the "moduleNameMapper" config option.

    You'll find more details and examples of these config options in the docs:
    https://jestjs.io/docs/configuration
    For information about custom transformations, see:
    https://jestjs.io/docs/code-transformation

    Details:

    /Users/rahuldesai/falcon-ui/node_modules/p-limit/index.js:1
    ({"Object.<anonymous>":function(module,exports,require,__dirname,__filename,jest){import Queue from 'yocto-queue';
                                                                                      ^^^^^^

    SyntaxError: Cannot use import statement outside a module

      1 | import moment from 'moment-timezone';
    > 2 | import pLimit from 'p-limit';
        | ^
      3 |

      at Runtime.createScriptFromCode (node_modules/jest-runtime/build/index.js:1728:14)
      at Object.<anonymous> (src/ducks/inventory/softwareTable/index.js:2:1)

I can't seem to use nested limit() function

So I have a Promise.all that's mapping an array to a limit, that's calling a function. In that function I have another Promise.all that I want limited, but it seems to never get into the second limit function call.

Any ideas?

If promises are generated ad-hoc, p-limit doesn't execute some of them

I have some code which is firing off promises on an "ad-hoc" basis. I need to limit how many are actually executing at the same time (else too many open network connections, etc.)

Using p-limit it never fires a promise if it comes in whilst all concurrent capacity is in-use.

A quick demo of this issue:

import delay from 'delay';
import pLimit from 'p-limit';

const limit = pLimit(1);

const wasteTime = async (value) => {
  await delay(1000);
  return value;
};

let count = 0;
setInterval(async () => {
  count += 1;
  console.log(await limit(() => wasteTime(count)));
}, 500);

I would expect to see output of:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

etc.

But instead I see:

1
2
4
6
8
10
12
14

It looks like the functions called when the pool is busy never execute?

Check if concurrency is defined

const pLimit = require('p-limit');

const limit = pLimit(undefined);

doesn't fail

target node or browser or both?

hey!
Does this target node or browser or both?

would love one line in the readme on this!

v5 can break due to subpath imports - node+deno unable to resolve core modules re imports map

I reported this: nodejs/node#51009
initially reported to tsx here: privatenumber/tsx#425

The minimal repro from the tsx issue (on StackBlitz) uses p-limit for the demo.

I encountered the issue when bumping packages in a TypeScript cli project to current (including bumping p-limit v4 to v5) that runs via tsx (with module "ESNext" in the tsconfig).

The trigger of the issue in p-limit is right here:
v4.0.0...v5.0.0#diff-e727e4bdf3657fd1d798edcd6b099d6e092f8573cba266154583a746bba0f346R2

Given the circumstances I'm not sure if you want to do anything differently, however I figured I'd create an issue here to put it on your radar, in case you want to accommodate on account of the popularity of this package. Thanks!

syntax error

here is syntax error in code

const run = async (fn, resolve, args) => {
	activeCount++;

	const result = (async () => fn(...args))();

	resolve(result);

	try {
		await result;
	} catch {}

	next();
};

it will case something wrong;

try catch from mdn
https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Statements/try...catch

Feature request: Ability to clear the queue

I'm not sure if this is a feature you'd want here, happy to open a PR if so.

In addition to being able to read the values for activeCount and pendingCount, I would like also to be able to clear the queue.

The driving use case is that I would like to only run with the latest arguments if there are pending calls. E.g. I have a function that performs an expensive API based validation, and I only care about the current state of things, not the intermediary state.

Is this a feature that you believe should live here? Thanks in advance.

Function sometimes run synchronously, sometimes asynchronously

If you pass in a function to a Limit, if there's space in the queue it runs the function synchronously. If there isn't, of course it runs later. This makes the performance characteristics of enqueuing unpredictable, and results in state sometimes changing before the next line of code, and sometimes not. (My team affectionately refers to the set of subtle bugs that this "sometimes-sync-sometimes-async" behavior can call as "zalgo".) It would be nice if enquing always deferred the enqueued function at least until the next tick.

Add "types" to package.json

Right now the TypeScript definition is not getting picked up.

Adding "types": "index.d.ts" to package.json should fix this.

ERROR Error loading vue.config.js Error SyntaxError: Unexpected token {

environment: node v8.11.1
use vuecli3 to build front project

throw error: node_modules/terser-webpack-plugin/node_modules/p=limit/index.js:29
Unexpected token {

} catch {}

should use

catch(err) { 
 // deal catch error
}

Can't require("p-limit")

I am trying to load this module using:
const pLimit = require("p-limit");

However when I do that I get the following error:

import Queue from 'yocto-queue';
^^^^^^
SyntaxError: Cannot use import statement outside a module
at wrapSafe (internal/modules/cjs/loader.js:1116:16)
at Module._compile (internal/modules/cjs/loader.js:1164:27)
at Object.intercept [as .js] (/home/hamzaafridi/Workspace/app.vetdrive.co/master/node_modules/amdefine/intercept.js:30:12)
at Module.load (internal/modules/cjs/loader.js:1049:32)
at Function.Module._load (internal/modules/cjs/loader.js:937:14)
at Module.require (internal/modules/cjs/loader.js:1089:19)
at Module.Hook._require.Module.require (/home/hamzaafridi/.npm/lib/node_modules/pm2/node_modules/require-in-the-middle/index.js:80:39)
at require (internal/modules/cjs/helpers.js:73:18)
at Object.<anonymous> (/master/src/server/modules/print.js:2:16)

Can someone please help?

Thanks!

this code is wrong

The try catch code on lines 28 to 31 is wrong，it should be
try {await result;} catch(e) {}
Now, when i build my project, this wrong broken the process

how should i use clearqueue?

I want to stop the pending tasks

Module not found: Can't resolve '#async_hooks'

Hi,

Since the update of v5.0.0 (updating from 4.0.0) I now get the following error:

⨯ ./node_modules/p-limit/index.js:2:0
Module not found: Can't resolve '#async_hooks'

My environment is NextJS 14, Node JS 20.8.0

I did not have the issue with pLimit v4.0.0

I see in the diff between 4.0.0 and 5.0.0 a new line for the usage of
import {AsyncResource} from '#async_hooks';

so the error is definitely coming from this update.

I also read a warning on the NodeJS webpage version 21.1 about the usage of async_hook: source: https://nodejs.org/api/async_hooks.html

Async hooks
Stability: 1 - Experimental. Please migrate away from this API, if you can. We do not recommend using the createHook, AsyncHook, and executionAsyncResource APIs as they have usability issues, safety risks, and performance implications. Async context tracking use cases are better served by the stable AsyncLocalStorage API. If you have a use case for createHook, AsyncHook, or executionAsyncResource beyond the context tracking need solved by AsyncLocalStorage or diagnostics data currently provided by Diagnostics Channel, please open an issue at https://github.com/nodejs/node/issues describing your use case so we can create a more purpose-focused API.

Is it safe to be used then? Is this API compatible with node 20 and below ?

Thank you.

Unexpected token

node scripts/build.js

Creating an optimized production build...
Failed to compile.

./node_modules/_p-limit@3.0.1@p-limit/index.js
Module parse failed: Unexpected token (30:10)
You may need an appropriate loader to handle this file type.
| try {
| await result;
| } catch {}
|
| next();

my node vesion is v12.16.1