Object schemas with values of any or unknown

[johngeorgewright]

I just came across something which surprised me and I wanted to enquire if this is expected or a bug. When using an object, looseObject or strictObject schema where values are unknown() or any(), trying to parse an object without those fields will pass. For example:

import { object, parse, unknown } from 'valibot'

parse(
  object({
    foo: unknown(),
  }),
  {},
)
// ✅ SUCCESS!

However, if I were to change foo's schema to something else, it will not...

import { object, parse, string } from 'valibot'

parse(
  object({
    foo: string(),
  }),
  {},
)
// 🚫 FAIL!
// Invalid type: Expected string but received undefined

Is anyone able to confirm whether I've found a bug or I'm missing a point?

[johngeorgewright]

I think I can answer my own question by inferring the type...

const schema = object({ foo: unknown() })
type Schema = InferOutput<typeof schema>
const a: Schema = {}
// Error!

Looks like a bug to me.

[fabian-hiller]

The object schema does not distinguish between missing and undefined entries for reasons of bundle size and simplicity. It treats missing keys as undefined. This is intended and documented, but I understand why it might be confusing in this case.

[johngeorgewright]

Ah, OK. I guess my biggest struggle here is that the type inferring is different to the runtype checking. Would it be at all possible to align the returned type with this intention? Something like:

const schema = object({ foo: unknown() })

type Schema = InferOutput<typeof schema>
// { foo?: unknown }

This way there is much less confusion and the only potential increase in bundle size is in types, which will eventually be stripped out.

[fabian-hiller]

Yes, this is possible, and I can see why it might make sense. On the other hand, if we change this, we would be taking control of the type signature away from the user. Currently they can decide if they want a question mark or not by warping the schema in optional.

[johngeorgewright]

In the example above the parameter foo is optional as you don't need to specify it and the parsed result might not contain it. Currently, however, the type will suggest the complete opposite. To me it would seem beneficial that the types would reflect run time.

I have, however, managed to get around my original problem by using the required schema... in case anyone else was thrown by this.

const schema = v.required(v.object({ foo: v.unknown() }), ['foo'])

Using the above will align both the runtime and compile time validation. And similarly you could specify that foo is optional. Either option will provide the correct type.

[fabian-hiller]

required basically just wraps foo with nonOptional. So you could also use nonOptional directly in this case.

What object does by ignoring the difference between missing and undefined keys is not optimal, but I chose this way in favor of bundle size and simplicity, and since it is an edge case it makes no difference in most cases. Since this is deliberately non-optimal, I don't want to affect other parts of the library and make them non-optimal as well. Even if there is a difference between runtime and type signature, the current implementation is probably the best compromise. I remember in the early days we marked unknown as optional, and people complained about it.