Invalid key: Expected \"...\" but received undefined

[felipedeboni]

I've found a problem with custom error messages, not sure when it started tho.

Example schema:

const Schema = v.object({
  email: v.pipe(
    v.string("Whoops! It should be a string."),
    v.nonEmpty("Looks like your forgot to tell what is your email."),
    v.email("Your email must be valid.")
  ),
});

Current behavior:

If the object being validate does not have the key, looks like an internal message is returned, while all other options have a "fancy" message.

// message is "Invalid key: Expected \"email\" but received undefined",
const result1 = v.safeParse(Schema, {}); 

// message is "Whoops! It should be a string." 
const result2 = v.safeParse(Schema, { email: undefined });
const result3 = v.safeParse(Schema, { email: null });
const result4 = v.safeParse(Schema, { email: 1 });

Expected output:

All calls should return the same message Whoops! It should be a string. for the email key.

Reproduction:

Playground link

[fabian-hiller]

Hey, this is intentional. There's a difference between a missing object entry and a present, undefined one. Take a look at issue #1034 for more details and possible workarounds.

[felipedeboni]

@fabian-hiller we can agree to disagree, in the end it's the same for those using valibot. Reading the link you sent, the major concern seems to be about bundle size right?

However adding the same thing for almost all required fields wouldn't be worst?!
Looks like it's just a transfer of bundle size and complexity to whoever is consuming it, without to mention the massive PITA.

Don't get me wrong, valibot is amazing and I use it almost everywhere I need a validation and I really appreciate what you've done so far, however this behavior is far from being nice and actually expected.

Also please consider the following:

const response = await fetch("https://example.org/post", {
  method: "POST",
  body: JSON.stringify({ email: undefined }), // serializes to '{}'
  // …
});

Which will basically force every single required property on Schema to handle this design decision using a hacky solution.

Pretty please, go back to the old behavior.