Improve `summarize()` to show nested validation errors

[nktkas]

Problem:
v.summarize() only shows the top-level error message without revealing the actual validation failures inside.

Example:

import * as v from "valibot";

const schema = v.union([
  v.object({ type: v.literal("admin"), role: v.string() }),
  v.object({ type: v.literal("user"), age: v.number() }),
]);
const data = { type: "unknown", role: 123, age: "invalid" };

const result = v.safeParse(schema, data);
if (!result.success) {
  console.log(v.summarize(result.issues));
}

Current output:

× Invalid type: Expected Object but received Object

Suggested fix:

import * as v from "valibot";

/**
 * Summarize the error messages of issues in a pretty-printable multi-line string.
 *
 * @param issues The list of issues.
 *
 * @returns A summary of the issues.
 *
 * @beta
 */
// @__NO_SIDE_EFFECTS__
export function summarize(
  issues: [v.BaseIssue<unknown>, ...v.BaseIssue<unknown>[]],
): string {
  // Create variable to store summary
  let summary = "";

  /** Recursively process issues with indentation */
  function processIssues(
    issueList: v.BaseIssue<unknown>[],
    indent: string = "",
  ): void {
    for (const issue of issueList) {
      // Add newline if summary is not empty
      if (summary) {
        summary += "\n";
      }

      // Add message to summary with current indentation
      summary += `${indent}x ${issue.message}`;

      // Get dot path from issue
      const dotPath = v.getDotPath(issue);

      // If dot path is available, add it to summary
      if (dotPath) {
        summary += `\n${indent}  → at ${dotPath}`;
      }

      // Process nested issues recursively with increased indentation
      if (issue.issues && issue.issues.length > 0) {
        processIssues(issue.issues, indent + "  ");
      }
    }
  }

  // Process all issues
  processIssues(issues);

  // Return summary
  return summary;
}

New output:

x Invalid type: Expected Object but received Object
  x Invalid type: Expected "admin" but received "unknown"
    → at type
  x Invalid type: Expected string but received 123
    → at role
  x Invalid type: Expected "user" but received "unknown"
    → at type
  x Invalid type: Expected number but received "invalid"
    → at age

P.S.: suggested fix is just an example, most likely there are edge cases that it doesn't handle well

[fabian-hiller]

Hey, thank you for reaching out! I think the actual problem is that you are using the union schema instead of variant. Subissues are very rare and can often be avoided by refactoring the schema. If this is not possible, subissues will usually contradict each other, so I'm not sure if including them in summarize would be helpful. In this case I would recommend adding a custom error message to union that is than displayed in the output of summarize . However, I am still open to discussing this. Your implementation and formatting look good to me.

[nktkas]

Hey, thanks for reminding me about variant. union is easier to use, and I didn't pay attention to the drawbacks.

However, there are cases when variant cannot be used and the data cannot be adjusted, for example:

const schema = v.union([
  v.object({
    admin: v.object({ role: v.string() }),
  }),
  v.object({
    user: v.object({ age: v.number() }),
  }),
]);
const data = { user: { age: "invalid" } };

In such cases, it is more convenient to see this error (explanation of why the data does not fit each scheme):

x Invalid type: Expected Object but received Object
  x Invalid key: Expected "admin" but received undefined
    → at admin
  x Invalid type: Expected number but received "invalid"
    → at user.age

Rather than simply:

x Invalid type: Expected Object but received Object

[fabian-hiller]

I think I agree. What do you think about cases like v.union([v.string(), v.number(), v.boolean()]). Are showing the subissues useful or confusing there? Feel free to create a PR!

[nktkas]

What do you think about cases like v.union([v.string(), v.number(), v.boolean()]). Are showing the subissues useful or confusing there?

In this case, the standard error x Invalid type: Expected (string | number | boolean) but received null is already quite informative.

Probably only Object (and maybe Array) requires improvement in description.

[fabian-hiller]

If variant solved the initial issue, I would wait until a few more devs reach out before changing summarize. Are you cool with that?