Serialize err.cause in a nice way when possible

[voxpelli]

Fixes #76, see that for a description

I did some other tweaks at #77, which I needed to get this patch working locally

[voxpelli]

Opps, wrong content, will push update

[voxpelli]

Fixed

[mcollina]

lgtm

[mcollina]

Could you add some docs here?

Could you open a matching PR in the pino repo to document this too?

[jsumners]

Why is the message a concatenation of the three errors? Can you show an example of the full serialized error?

[voxpelli]

It's because all three describe the error that has happened, but at three different levels. An example:

If err consists of thrown and wrapped errors in these three steps:

1. ENOENT, stat '/nonexistent'
2. Failed to open cache
3. Can't cache example.com/robots.txt

Then when someone does:

pino.warn(err, 'robots.txt lookup failed');

It will log:

{
  "message": "Can't cache example.com/robots.txt: Failed to open cache: ENOENT, stat '/nonexistent'"
  "stack": `Error: Can't cache example.com/robots.txt
    at Object.<anonymous> (/examples/fullStack.js:5:12)
caused by: Error: Failed to open cache:
    at Object.<anonymous> (/examples/fullStack.js:3:12)
caused by: Error: ENOENT, stat '/nonexistent'
    at Object.<anonymous> (/examples/fs.js:4:15)`
}

[voxpelli]

So the idea is that the top most error should only describe the error on its abstraction level, not on any of the lower levels, but rather refer to the error causes for adding those description at those levels.

This makes it easy to distinguish between Can't cache example.com/robots.txt errors caused by Failed to open cache if there's also another reason going around that's maybe Malformed cache file content.

Here's a real life example: https://github.com/dependency-check-team/dependency-check/blob/c0537d04452098208132c6633277374dc9ad0a8d/lib/resolve-target.js#L40-L43

[jsumners]

Okay. My biggest concern was that I thought I was using the standard error serializer from this package and that this change in message shape would break me. But it seems I'm not using it. Still, this will be a semver major change unless it serializes like:

{
  "message": "three",
  "stack": "...",
  "cause": {
    "message": "two",
    "stack": "...",
    "cause": {
      "message": "one",
      "stack": "..."
    }
  }
}

[voxpelli]

If we keep the nested cause and only extend stack, then I think we can make it a minor, then follow up with message + removing redundant cause in a major?

Thoughts @jsumners @mcollina?

[voxpelli]

Thinking a bit more about this, I think safest would be to simply make this a major change and make all changes at once

[jsumners]

How much effort would it take to implement without a dependency? Going from zero to greater than zero dependencies is not ideal.

[voxpelli]

How much effort would it take to implement without a dependency? Going from zero to greater than zero dependencies is not ideal.

Not a huge effort, simplest would be a copy and paste from my module: https://github.com/voxpelli/pony-cause/blob/1f1dff84a54a44e5253fa6382c9d32d37943d747/index.js#L60-L161

100 lines including type comments then

[mcollina]

Let's do that

[jsumners]

How much effort would it take to implement without a dependency? Going from zero to greater than zero dependencies is not ideal.

Not a huge effort, simplest would be a copy and paste from my module: https://github.com/voxpelli/pony-cause/blob/1f1dff84a54a44e5253fa6382c9d32d37943d747/index.js#L60-L161

100 lines including type comments then

If that is okay with you, let's do that.

[voxpelli]

Moved relevant code from pony-cause into this module.

What I didn't move: All of the relevant tests: https://github.com/voxpelli/pony-cause/tree/main/test They are not needed here unless individual development of the code will be done here + they are written in Mocha/Chai rather than tap, so wouldn't be a simple 1:1 copy :)

Any additional thing I should change/do` @jsumners @mcollina?

[mcollina]

lgtm

[jsumners]

Looks good to me. Semver major.

[mcollina]

Should we bump it in pino@7? I think so.

[voxpelli]

I should add some documentation around this as well, right? Shall we create an issue and assign it to me?

[jsumners]

Should we bump it in pino@7? I think so.

I'm torn. This is a big change to the output of errors. But people shouldn't be parsing the text of logged errors anyway?

I should add some documentation around this as well, right? Shall we create an issue and assign it to me?

Sure.