Value or undefined is not the same as an optional, and should not be a required property either

[emanuel-lundman]

type A = {
    b: string | undefined
}

is not the same as:

type A = {
    b?: string | undefined
}

The first requires undefined to be set, and can't just be left out.

Zod though both seem to infer:

type A = {
    b: string | undefined
}

to an optional when writing the schema first and then inferring a type. And when doing the other way around, writing a schema for the type, thinks it's required and only accepts the following:

type A = {
    b: string | undefined
}

const a = z.ZodScheme<A> = z.object({
    b: z.string()
})

even though it should be z.string().or(z.undefined())
But writing is it should be results in error:
Property 'b' is optional in type '{ b?: string | undefined; }' but required in type 'A'

Am I missing something?

[JacobWeisenburger]

I guess I'm not really seeing what problem you are talking about. I tested 2 situations and they both seem to be working as expected. Please help me to understand what is not working correctly.

type A = {
    b: string | undefined
}

const a: z.ZodSchema<A> = z.object( {
//    ^
// Property 'b' is optional in type '{ b?: string | undefined; }' but required in type 'A'.
    b: z.string().optional(),
} )

type inferredA = z.infer<typeof a>
// type inferredA = {
//     b: string | undefined;
// }

const foo: z.infer<z.ZodSchema<{ b?: string | undefined }>> = {} // no error
const bar: z.infer<z.ZodSchema<{ b: string | undefined }>> = {} // error
//    ^^^
// Property 'b' is missing in type '{}' but required in type '{ b: string | undefined; }'.

[emanuel-lundman]

@JacobWeisenburger
I guess what I got caught in is how to write the zodtype without inferring.
Must have made a mistake when I tested to infer since it works with your inferring example for me as well now.
The inferring part that is. But:

type A = {
    b: string | undefined
}

const a: z.ZodSchema<A> = z.object({
    b: z.union([z.string(), z.undefined()])
})
// ^^ also throws: Property 'b' is optional in type '{ b?: string | undefined; }' but required in type 'A'.ts(2322)
// (same with z.string().or(z.undefined()))

So, question I still have is, how do I write the union of string | undefined when it's not an optional?
z.string().or(z.undefined()) and z.union([z.string(), z.undefined()])
shouldn't be optional? should they?

const a: z.ZodSchema<A> = z.object({
    b: ????
})

[JacobWeisenburger]

It seems that somewhere in z.object(), anything that undefined can extend from, gets converted to optional. I'm exactly not sure why zod does it this way. I suggest that you use null instead of undefined for your use case. Because then the property is required, and null can be coerced to undefined and vice versa.

type A = {
    b: string | null
    c: string | null
    d: string | null
}

// You could define your zod schema any of the 3 ways below.
const a: z.ZodSchema<A> = z.object( {
    b: z.union( [ z.string(), z.null() ] ),
    c: z.string().or( z.null() ),
    d: z.string().nullable(),
} )

---

https://stackoverflow.com/questions/5076944/what-is-the-difference-between-null-and-undefined-in-javascript

[emanuel-lundman]

@JacobWeisenburger
Know about the difference between null and undefined. In our code base by choice we don't use null, we took the decision to only use undefined and it has been great. There's really no need to use them both. I realize it's a matter of opinion but to us it's just a complication to use them both. Especially when using typescript.

Anyway, I would consider it a bug with zod if it's impossible to write the union of e.g. string | undefined since it is possible in typescript. I believe this issue should be an issue again and not a discussion?

[JacobWeisenburger]

Ok fair enough. I'll change it back

[iambryanhaney]

Just ran into this and consider it unexpected behavior myself.

An example with an explicit transform:

property: z.string().transform((v) => v || undefined)
// { property?: string | undefined }

A workaround is to transform the containing object:

z.object({
  property: z.string(),
})
.transform((obj) => ({ ...obj, property: obj.property || undefined }));
// { property: string | undefined }

[bluepnume]

Would love to have a solution like this. I have a lot of scenarios where I want to force the caller to pass undefined if they don't want to pass a value, like @emanuel-lundman we are trying to stick to undefined only, no null.

It would be amazing to have schema.or(z.undefined()) work in the expected way, which is different than schema.optional(), and it would be closer to TS semantics too.

[paulieDOTjs]

I, too, would love a solution for this. In like @bluepnume and @emanuel-lundman said trying to verify something with explicitly set undefined and with optional keys are very different things.

type User{
 name: string;
 email: string | undefined
}

is completely different than

type User {
  name: string;
 email?: string
}

In our codebase we are still using nulls and find a lot of use cases for differing between a null, undefined or optional value in an object's value.

[hrasoa]

Run into the same issue, z.undefined() should not make the property optional, there is z.optional for that.
In instance, valibot is correct here:

[jack-bliss]

just weighing in to say that i also would not expect unioning with undefined to automatically make the field optional. typescript already explicitly differentiates between property?: string and property: string | undefined, so it would be nice if zod could too!

[hurrymaplelad]

+1

Object spreads are a common place where the difference matters:

const x = {
  a: 1,
  b: 2,
};

const y = {
  a: 2,
  b: undefined,
};
 
const z = {
  a: 3
}; 

({...x, ...y}).b // undefined
({...x, ...z}).b // 2

I often rely on omitted keys to spread in default values. Zod could make this simpler by offering a schema that can coerce null or undefined to an omitted key.

[darcyrush]

Just to link the issue to this discussion; #3186