[Content collections] Better error formatting

[bholmesdev]

Changes

This fixes a few problems in today's error formatter:

• The collection -> entry path is bolded for visibility
• Frontmatter keys are now always placed at the start of an error message. This fixes inconsistencies where the key name could be at the start of the end of a message.
• Union errors now log "Did not match union" instead of "Invalid input." Will also log "type" and "invalid literal" errors for keys shared by all members of a union.
• Unhandled errors now correctly fall through to Zod's error message. This would log "Invalid Input" for all unhandled messages before.

Example: a union between { key: z.literal('tutorial') } and { key: z.literal('blog') } will raise a single error when key does not match:

Did not match union.
> key: Expected `'tutorial' | 'blog'`, received 'foo'

Before / after

Here is a before and after of the error experience when authoring in docs.astro.build. These errors are based on the union schema configured here.

Example invalid frontmatter:

---
type: guide
i18nReady: maybe?
---

Before

After

Testing

• Unit test error map

Docs

• Small change to errors data: formatting and slight message change

[changeset-bot]

🦋 Changeset detected

Latest commit: 13887e0

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[jasikpark]

Curious if there's anything to upstream / open source as a general solution once this merges 😁 looking amazing

[bholmesdev]

Flagging for docs review @sarah11918 👀

[sarah11918]

@bholmesdev I love the change overall! And, I know you wanted something shorter here, but I don't love "invalid" vs "does not match what you said you wanted here." (which is why it's invalid)

If you feel the need to shorten, something like ...

"unexpected frontmatter" feels a little more user friendly?

Your call! Non-blocking!

[bholmesdev]

Understood! Didn't feel too strongly about this change. I think I'll revert to the old wording, with the bolding added 👍

[bholmesdev]

@jasikpark Already want to bring this to our RSS config handler! Also throws a big ole Invalid input for some of the types.

[jasikpark]

this is CLEAN 👏 quick glance over looks great to me, though I haven't tested or thought through the logic

[jasikpark]

reads similar to https://github.com/causaly/zod-validation-error - maybe there's interesting prior art there for how to generalize this, tho ig it probably looks exactly the same lol

[bholmesdev]

@jasikpark I gave that library a try! Didn't like that keys were listed at the end of an error instead of the beginning (i.e. Required at "key" instead of "key": Required). Also doesn't have the union error handling and bolding that we have here. Thanks for mentioning that though, not sure how we could align this with their approach without an explosion of config options 😅

[sarah11918]

Left a comment! I might try to go for more surprise than judgement, but non-blocking!

[jasikpark]

@bholmesdev yep didn't think it'd be a drop-in at all, just wanted to make you aware / show that there's existing interest in the concept of "give me pretty error messages from a zod validation error"

[yanthomasdev]

That's a great improvement, nice work @bholmesdev! Docs LGTM 🙌