feat: pretty print diffs coming from cause

[dubzzz]

Description

This Pull Request adds support for diffs coming nested errors. In the context of Error with cause, if the cause is an Error coming with a diff, the current version of Vitest does not render it in a diff fashion. It tends to make understanding such nested errors complex. The proposal implemented by this PR is to display the diff attached to causes.

Let's consider the following snippet:

import { test, expect } from "vitest";

const value1 = { a: 1, b: 2, c: 3, e: 4, f: 5, g: 6, h: 7, i: 8, j: 9, k: 10 };
const value2 = { a: 1, b: 2, c: 3, e: 4, f: 5, g: 6, h: 7, i: 88, j: 9, k: 10 };

test("rethrown expect as cause", () => {
  try {
    expect(value1).toEqual(value2);
  } catch (err) {
    throw new Error("failed!", { cause: err });
  }
});

Before	After

Why is rewrapping an Error within a cause a pattern that should be considered? Property Based Testing and Fuzzing frameworks usually rewrap thrown exceptions into their own exception. When leveraging Error with cause mechanisms they may expose the source Error as a cause of their own Error.

Example of fuzzing with fast-check

Considered code:

import { test, expect } from "vitest";
import fc from "fast-check";

fc.configureGlobal({ errorWithCause: true });
const value1 = { a: 1, b: 2, c: 3, e: 4, f: 5, g: 6, h: 7, i: 8, j: 9, k: 10 };

test("fuzz", () => {
  fc.assert(
    fc.property(fc.nat(), (i) => {
      expect(value1).toEqual({ ...value1, i });
    })
  );
});

Before	After

More on fast-check at fast-check.dev

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
• Ideally, include a test that fails without this PR but passes with it.
• Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.

Tests

• Run the tests with pnpm test:ci.

Documentation

• If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

• Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.

[netlify]

✅ Deploy Preview for fastidious-cascaron-4ded94 canceled.

Name	Link
🔨 Latest commit	890e82b
🔍 Latest deploy log	https://app.netlify.com/sites/fastidious-cascaron-4ded94/deploys/6635d82a57e9d5000898f574

[sheremet-va]

1. Is there any reason why you don't assign the cause?
2. If we have this recursion, then #L125-126 are not needed anymore

[dubzzz]

The code of processError is actually performing a set of side-effects on the passed instance. By calling processError(err.cause, diffOptions), I'm actually updating err.cause in place.

Well good point for #L125-126. I'll check back, but they might not be needed anymore as the code I added will recursively sanitize the causes. By the way it will not only sanitize the first level but all the others.

[dubzzz]

I treated the 2. Regarding the 1, I could have done:

err.cause = processError(err.cause, diffOptions);

But I feel it might be more risky as re-assigning .cause is not needed. It may throw. As we alter it in-place during the call, there is no real need to re-assign (re-assigning to itself). I wrote not in italic as actually they are some cases that may justify the attempt to reassign as in some code paths the returned value is not self.

[dubzzz]

If I'm ignoring the result I might just split processError into two functions: one sanitizing, the other serializing. That's said I'll go for the re-assignment idea for my attempt. Let me know what's the best option in your opinion.