sindresorhus/aggregate-error

Create an error from multiple errors

i love code    and unicorns  

check out my latest app: Icon Preview

and my latest blog post

aggregate-error's Issues

Thoughts on requiring Node 14?

Thank you for all your open-source work.

I'm a user of p-* libraries, and it would be great to have the improved browser support implemented in the latest clean-stack (sindresorhus/clean-stack@dccdb49). From what I can tell, the braking changes in clean-stack v5 relate to node requirements.

I'm happy to open a PR, but wanted to ask if there is perhaps some reason to keep Node 12 support in this library.

message generation breaks when AbortError/Error without stack is encountered

Hi,

I’m not quite sure if this is a bug that should be handled here or in the clean-stack lib, but when using abortable fetch requests on ArchLinux with Chromium 72.0.3626.96 a DOMException/AbortError is thrown that, even though it is an instance of Error, does not have a stack (it’s simply undefined). I’ve yet to confirm if this is standard-compliant and/or happens in other browsers but for the sake of being robust I think it would be a good idea to actually check if err.stack exists during the generation of message.

Example (bundled version):

import AggregateError from 'aggregate-error'

const { fetch, AbortController } = window
const controller = new AbortController()
const signal = controller.signal

fetch('https://api.github.com/', { signal })
  .then(res => res.json())
  .then(data => { console.info(data) })
  .catch(err => Promise.reject(new AggregateError([new Error('something went south during github api request'), err]))

controller.abort()

cheers Konrad

Update clean-stack dependency to latest version

Please update the clean-stack dependency to v5.2.0

Vite v4.4.9 warns: Module "os" has been externalized for browser compatibility. Cannot access "os.homedir" in client code.
This come from code in clean-stack v4.0.0. I've looked at clean-stack v5.2.0 and it uses a new home-directory modules which I assume resolves this warning.

low level browsers do not support private-methods

low level browsers do not support private-methods

npm version v4

Make it more spec compliant

When used with mocha the errors are displayed twice. Is there a way to have it only display once?

const AggregateError = require('aggregate-error')

it('should fail', function() {
  throw new AggregateError([
    new Error('first'),
    new Error('second')
  ])
})

The report is

  1) should fail

  0 passing (12ms)
  1 failing

  1) should fail:
     
    Error: first
        at Context.<anonymous> (/Users/williamrusnack/Documents/event_sequencing/try_aggregate-error.js:5:5)
        at callFn (/Users/williamrusnack/Documents/event_sequencing/node_modules/mocha/lib/runnable.js:354:21)
        at Test.Runnable.run (/Users/williamrusnack/Documents/event_sequencing/node_modules/mocha/lib/runnable.js:346:7)
        at Runner.runTest (/Users/williamrusnack/Documents/event_sequencing/node_modules/mocha/lib/runner.js:442:10)
        at /Users/williamrusnack/Documents/event_sequencing/node_modules/mocha/lib/runner.js:560:12
        at next (/Users/williamrusnack/Documents/event_sequencing/node_modules/mocha/lib/runner.js:356:14)
        at /Users/williamrusnack/Documents/event_sequencing/node_modules/mocha/lib/runner.js:366:7
        at next (/Users/williamrusnack/Documents/event_sequencing/node_modules/mocha/lib/runner.js:290:14)
        at Immediate.<anonymous> (/Users/williamrusnack/Documents/event_sequencing/node_modules/mocha/lib/runner.js:334:5)
    Error: second
        at Context.<anonymous> (/Users/williamrusnack/Documents/event_sequencing/try_aggregate-error.js:6:5)
        at callFn (/Users/williamrusnack/Documents/event_sequencing/node_modules/mocha/lib/runnable.js:354:21)
        at Test.Runnable.run (/Users/williamrusnack/Documents/event_sequencing/node_modules/mocha/lib/runnable.js:346:7)
        at Runner.runTest (/Users/williamrusnack/Documents/event_sequencing/node_modules/mocha/lib/runner.js:442:10)
        at /Users/williamrusnack/Documents/event_sequencing/node_modules/mocha/lib/runner.js:560:12
        at next (/Users/williamrusnack/Documents/event_sequencing/node_modules/mocha/lib/runner.js:356:14)
        at /Users/williamrusnack/Documents/event_sequencing/node_modules/mocha/lib/runner.js:366:7
        at next (/Users/williamrusnack/Documents/event_sequencing/node_modules/mocha/lib/runner.js:290:14)
        at Immediate.<anonymous> (/Users/williamrusnack/Documents/event_sequencing/node_modules/mocha/lib/runner.js:334:5)
  AggregateError: 
      Error: first
          at Context.<anonymous> (try_aggregate-error.js:5:5)
      Error: second
          at Context.<anonymous> (try_aggregate-error.js:6:5)
      at Context.<anonymous> (try_aggregate-error.js:4:9)

Tests are failing on master

> npm test

> [email protected] test /Users/felix/git/aggregate-error
> xo && ava


  index.js:20:15
  ✖  20:15  The name property should be set to AggregateError.  unicorn/custom-error-definition

  1 error
npm ERR! Test failed.  See above for more details.

xo is failing, seems a bit dangerous to depend on xo@*?

Add message argument

Add a message argument to bring the constructor in line with the TC39 AggregateError proposal.

Before

new AggregateError(errors)

After

new AggregateError(errors[, message])

The message is simply written to error.message property.

Handling errors without stacks

Ref: sindresorhus/clean-stack#1

Use native AggregateError if available

I see the hint in the readme that modern node has it, but I don't see feature detection code in index.js and

$ node -e 'import("aggregate-error").then(({ default: AE }) => console.log({
>   v: process.versions.node, AE, AggregateError, same: AE === AggregateError}))'
{
  v: '16.14.0',
  AE: [class AggregateError extends Error],
  AggregateError: [Function: AggregateError],
  same: false
}

question[TypeScript] How should AggregateError be imported as type when using TypeScript without esModuleInterop option

When trying to use AggregateError as type in a Typescript project the following issue happens:

Conditions

• To not use esModuleInterop in tsconfig.json

Tried alternatives

(this would not fit the purpose of getting the type)

---

(it implies enabling moduleInterop flag)

---

Question

Considering the way this library is exposing AggregateError, Is there a way to import AggregateError in a ESModule way as Typescript type (so, no const AggreagateError = require('aggregate-error') and without enabling esModuleInterop option?

Details

You can find more details in:

• https://github.com/octokit/webhooks.js/pull/248/files
• octokit/webhooks.js#245

support es5 syntax

hello ,could pease support es5 syntax? it will case error when runtime supports es5 only