Bump async from 1.5.2 to 3.2.3

[dependabot]

Bumps async from 1.5.2 to 3.2.3.

Release notes

Sourced from async's releases.

v2.3.0

• Added support for ES2017 async functions. Wherever you can pass a Node-style/CPS function that uses a callback, you can also pass an async function. Previously, you had to wrap async functions with asyncify. The caveat is that it will only work if async functions are supported natively in your environment, transpiled implementations can't be detected. (#1386, #1390)

v2.2.0

• Added groupBy, and the Series/Limit equivalents, analogous to _.groupBy (#1364)
• Fixed transform bug when callback was not passed (#1381)

v2.1.5

• Fix auto bug when function names collided with Array.prototype (#1358)
• Improve some error messages (#1349)
• Avoid stack overflow case in queue
• Fixed an issue in some, every and find where processing would continue after the result was determined.
• Cleanup implementations of some, every and find

v2.1.3

• Make bundle size smaller
• Create optimized hotpath for filter in array case.

v2.1.2

• Fixed a stackoverflow bug with detect, some, every on large inputs (#1293).

v2.1.0

• retry and retryable now support an optional errorFilter function that determines if the task should retry on the error (#1256, #1261)
• Optimized array iteration in race, cargo, queue, and priorityQueue (#1253)

v2.0.0

Lots of changes here!

First and foremost, we have a slick new site for docs. Special thanks to @​hargasinski for his work converting our old docs to jsdoc format and implementing the new website. Also huge ups to @​ivanseidel for designing our new logo. It was a long process for both of these tasks, but I think these changes turned out extraordinary well.

The biggest feature is modularization. You can now require("async/series") to only require the series function. Every Async library function is available this way. You still can require("async") to require the entire library, like you could do before.

We also provide Async as a collection of ES2015 modules. You can now import {each} from 'async-es' or import waterfall from 'async-es/waterfall'. If you are using only a few Async functions, and are using a ES bundler such as Rollup, this can significantly lower your build size.

Major thanks to @​Kikobeats, @​aearly and @​megawac for doing the majority of the modularization work, as well as @​jdalton and @​Rich-Harris for advisory work on the general modularization strategy.

Another one of the general themes of the 2.0 release is standardization of what an "async" function is. We are now more strictly following the node-style continuation passing style. That is, an async function is a function that:

1. Takes a variable number of arguments
2. The last argument is always a callback
3. The callback can accept any number of arguments
4. The first argument passed to the callback will be treated as an error result, if the argument is truthy
5. Any number of result arguments can be passed after the "error" argument
6. The callback is called once and exactly once, either on the same tick or later tick of the JavaScript event loop.

There were several cases where Async accepted some functions that did not strictly have these properties, most notably auto, every, some, and filter.

Another theme is performance. We have eliminated internal deferrals in all cases where they make sense. For example, in waterfall and auto, there was a setImmediate between each task -- these deferrals have been removed. A setImmediate call can add up to 1ms of delay. This might not seem like a lot, but it can add up if you are using many Async functions in the course of processing a HTTP request, for example. Nearly all asynchronous functions that do I/O already have some sort of deferral built in, so the extra deferral is unnecessary. The trade-off of this change is removing our built-in stack-overflow defense. Many synchronous callback calls in series can quickly overflow the JS call stack. If you do have a function that is sometimes synchronous (calling its callback on the same tick), and are running into stack overflows, wrap it with async.ensureAsync().

Another big performance win has been re-implementing queue, cargo, and priorityQueue with doubly linked lists instead of arrays. This has lead to queues being an order of magnitude faster on large sets of tasks.

... (truncated)

Changelog

Sourced from async's changelog.

v3.2.3

• Fix bugs in comment parsing in autoInject. (#1767, #1780)

v3.2.2

• Fix potential prototype pollution exploit

v3.2.1

• Use queueMicrotask if available to the environment (#1761)
• Minor perf improvement in priorityQueue (#1727)
• More examples in documentation (#1726)
• Various doc fixes (#1708, #1712, #1717, #1740, #1739, #1749, #1756)
• Improved test coverage (#1754)

v3.2.0

• Fix a bug in Safari related to overwriting func.name
• Remove built-in browserify configuration (#1653)
• Varios doc fixes (#1688, #1703, #1704)

v3.1.1

• Allow redefining name property on wrapped functions.

v3.1.0

• Added q.pushAsync and q.unshiftAsync, analagous to q.push and q.unshift, except they always do not accept a callback, and reject if processing the task errors. (#1659)
• Promises returned from q.push and q.unshift when a callback is not passed now resolve even if an error ocurred. (#1659)
• Fixed a parsing bug in autoInject with complicated function bodies (#1663)
• Added ES6+ configuration for Browserify bundlers (#1653)
• Various doc fixes (#1664, #1658, #1665, #1652)

v3.0.1

Bug fixes

• Fixed a regression where arrays passed to queue and cargo would be completely flattened. (#1645)
• Clarified Async's browser support (#1643)

v3.0.0

The async/await release!

There are a lot of new features and subtle breaking changes in this major version, but the biggest feature is that most Async methods return a Promise if you omit the callback, meaning you can await them from within an async function.

const results = await async.mapLimit(urls, 5, async url => {
    const resp = await fetch(url)
    return resp.body
})

Breaking Changes

... (truncated)

Commits

• 62943ca Version 3.2.3
• d2c9d51 Update built files
• de8d4c4 Update changelog for v3.2.3
• b015d34 fix: address edge case in comment stripping (#1780)
• e27aaab chore: remove unused Travis CI config (#1781)
• a038c8f ci: setup GitHub Actions (#1782)
• e74bd18 Core: const, let, arrow-fn and unused variables (#1776)
• 2ee673f Housekeeping (#1772)
• cdfb491 Fix an inefficient regex in autoInject (#1767)
• bb41f2a be explicit (#1769)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

[pull-request-quantifier-deprecated]

This PR has 0 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

---

Quantification details

Label      : No Changes
Size       : +0 -0
Percentile : 0%

Total files changed: 0

Change summary by file extension:

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

• Fast and predictable releases to production:
  • Optimal size changes are more likely to be reviewed faster with fewer
    iterations.
  • Similarity in low PR complexity drives similar review times.
• Review quality is likely higher as complexity is lower:
  • Bugs are more likely to be detected.
  • Code inconsistencies are more likely to be detetcted.
• Knowledge sharing is improved within the participants:
  • Small portions can be assimilated better.
• Better engineering practices are exercised:
  • Solving big problems by dividing them in well contained, smaller problems.
  • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

• Use the PullRequestQuantifier to quantify your PR accurately
  • Create a context profile for your repo using the context generator
  • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
  • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
  • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
• Change your engineering behaviors
  • For PRs that fall outside of the desired spectrum, review the details and check if:
    • Your PR could be split in smaller, self-contained PRs instead
    • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

• One line was added: +1 -0
• One line was deleted: +0 -1
• One line was modified: +1 -1 (git diff doesn't know about modified, it will
  interpret that line like one addition plus one deletion)
• Change percentiles: Change characteristics (addition, deletion, modification)
  of this PR in relation to all other PRs within the repository.

---

Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.