<!-- This template is for bug reports. If you are reporting a bug, please continue on. If you are here for another reason (such as a feature request, change, or question) you can disregard this template -->

What version of async are you using?

None; I chose not to use this library because re-inventing the wheel (in this case, the signature of "reduce") makes a library needlessly confusing, and that scared me away.

What did you do? Please include a minimal reproducable case illustrating issue. (NOTE: You misspelled "reproducible" in your issue template.)

From the docs:

async.reduce([1,2,3], 0, function(memo, item, callback) {

A Javascript reduce doesn't look like that; it looks like this (note that the initial value comes at the end):

[1,2,3].reduce(function(memo, item, callback) {}, 0);

Of course you have to take the array as an argument ... but you could still do that and otherwise be consistent with the Javascript API:

async.reduce([1,2,3], function(memo, item, callback) {}, 0);

Unless you're worried about people reducing with a function as an initial value, you could even fix this without breaking any code, by simply checking whether the 2nd arg is a function, and if it isn't only then treating it as the initial value.

What did you expect to happen?

I expect reduce in a library to work the same as reduce in Javascript, modulo any differences that must exist (ie. taking the array as an argument)..

What was the actual result?

If I use this library it's like going back to jQuery or something (which had $.forEach and $.map), where I had to memorize weird new ways to do basic things I already know how to do.

It's not worth doing a breaking change for this -- been this way for years. Sorry that the documented call signature was confusing and scary.

Hi, thanks for this!

I agree with @caub in #1609 -- the promise examples aren't that useful -- I think we should just have callback style, and async/await style, and also examples that use async iteration functions.

Nice, good work.

This applies the same technique that was done for queue in PR #1448 to priorityQueue. The change prevents multiple calls to setImmediate for queue processing that originate from calls to push on the same tick. The added overhead of the change is fairly negligible -- one variable assignment and two conditions.

$ perf/benchmark.js --grep priorityQueue
Latest tag is  v3.2.0
Comparing v3.2.0 with current on Node v12.13.1
--------------------------------------
priorityQueue(10) v3.2.0 x 16,503 ops/sec ±2.79% (27 runs sampled), 0.0606ms per run
priorityQueue(10) current x 17,979 ops/sec ±4.99% (28 runs sampled), 0.0556ms per run
current is faster
--------------------------------------
priorityQueue(100) v3.2.0 x 4,261 ops/sec ±1.90% (28 runs sampled), 0.235ms per run
priorityQueue(100) current x 4,749 ops/sec ±0.90% (28 runs sampled), 0.211ms per run
current is faster
--------------------------------------
priorityQueue(1000) v3.2.0 x 509 ops/sec ±1.06% (32 runs sampled), 1.96ms per run
priorityQueue(1000) current x 556 ops/sec ±1.17% (32 runs sampled), 1.80ms per run
current is faster
--------------------------------------
priorityQueue(30000) v3.2.0 x 13.02 ops/sec ±3.95% (24 runs sampled), 76.8ms per run
priorityQueue(30000) current x 14.79 ops/sec ±2.11% (27 runs sampled), 67.6ms per run
current is faster
--------------------------------------
priorityQueue(50000) v3.2.0 x 7.21 ops/sec ±2.82% (14 runs sampled), 139ms per run
priorityQueue(50000) current x 8.93 ops/sec ±3.04% (17 runs sampled), 112ms per run
current is faster
--------------------------------------
current faster overall (182ms total vs. 218ms total)
current won more benchmarks (5 vs. 0)

Several issues here:

• Missing the limit parameter
• There's nothing asynchronous about that code -- the iterating function doesn't use a callback or isnt async.
• async.eachLimit now returns a Promise if there's 3 parameters (i.e. no callback), so you're actually awaiting a promise that never resolves.

If updateProductByDate isn't asynchronous, you're better off just doing:

productsList.map(product => updateProductByDate(product))

Please give an example of code that isn't working. I can't help otherwise.

Set NODE_ENV=production as an environment variable, and the Object.freeze() is skipped.

https://github.com/aearly/icepick/blob/master/icepick.js#L77-L85

A lot of this is native JS now:

var fs = require('fs/promises'); // note the promises

async function main() { // top-level await coming in node 14
  await Promise.all(Object.keys(taskObj).map(async key => {
    const item = taskObj[key];
    return someAsyncFunction(item, key)
  }))
  await Promise.all([
    someAsyncFunction1(item, key),
    someAsyncFunction1(item, key)
  ]}
}
async function someAsyncFunction1(item, key) {
    return fs.writeFile( key + "-sAF1.txt", JSON.stringify(item), ?);
}

        async.mapLimit(wrss, 10, async function(rss) {
            const response = await parser.parseURL(rss.key)
            return response
        }, (err, results) => {
            if (err){
                console.log(err.toString())
                // return
            }
            // results is now an array of the response bodies
            
        })

This is a question.

Sorry if I'm repeating someone, but I couldn't find fast enough anything that answers it. What are the advantages of using this lib over native Promises? Does it make any thread handling or anything? Is it faster? etc.

Thanks in advance.

my code is as follow.

var transactions = ["1", "2", "3"]
async.each(transactions, async function(tx, callback) {
  console.dir(tx);
  console.dir(callback)
}, function(err) {})

the callback function is undefined

node v14.3.0 npm 6.14.5 ubuntu 18.04

async functions don't get passed a callback -- return a value, or throw an exception.

I am trying to do an async version of a for loop which is looping through pixels (so lots of iterations), and skipping 3 each time (as pixels each have 4 values).

for (var i - 0; i < pixels.length; i+=4) {}

eachOfLimit almost works, but if I input the pixels array as the collection, it does i++ each time rather than i+=4.

I tried using timesLimit, which was perfect as it ran the right number of times (pixels.length/4), and limited how many ran at once, except that it accumulates the results (even when the result is undefined / null), and I need the result from the last loop.

So then I tried doing it with doUntil, which is perfect even at the end as it just returns the last result, except now I'm exceeding the maximum call stack size (which makes sense because it can be potentially millions of iterations).

Am I missing a method that can do this, or does anyone have an idea of how to impliment it?

I'd avoid doing an async for loop over a pixel array -- it's going to be unusably slow.

doUntil seems like it would work, keeping track of the index yourself, but the call stack exception leads me to believe your processing is actually synchronous, in which case a basic for loop would work (and be way faster).

Low │ Prototype Pollution │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ Package │ lodash │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ Patched in │ No patch available │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ Dependency of │ vue-cli-plugin-electron-builder │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ Path │ vue-cli-plugin-electron-builder > portfinder > async > │ │ │ lodash │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ More info │ https://npmjs.com/advisories/1523

https://www.npmjs.com/advisories/1523

"No fix is currently available. Consider using an alternative package until a fix is made available."

So... can you use another package instead of lodash?

Environment Info:

  System:
    OS: Linux 5.3 Ubuntu 18.04.4 LTS (Bionic Beaver)
    CPU: (8) x64 Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
  Binaries:
    Node: 14.3.0 - ~/.nvm/versions/node/v14.3.0/bin/node
   Yarn: 1.22.4 - /usr/bin/yarn
    npm: 6.14.5 - ~/.nvm/versions/node/v14.3.0/bin/npm

[email protected]

Marco

Upgrade, or ignore this warning. We don't use the affected lodash methods.

There's no need to pause the queue once it drains. It'd be empty and nothing processing to pause.

I can't really help without some example code.