Restrict z.enum options to existing type

[IlyaSemenov]

Problem

I want to restrict options passed to z.enum to the existing type.

type Status = 'new' | 'accepted' | 'closed'

z.enum(['new', 'accepted']) // OK
z.enum(['new', 'approved']) // Invalid choice - should be somehow disallowed

Is there an elegant way to statically validate the typings of enum options?

Solutions tried

z.enum(['new', 'accepted'] as Status[]) // Argument of type 'Status[]' is not assignable to parameter of type '[string, ...string[]]'.
z.enum(['new', 'accepted'] satisfies Status[]) // Argument of type '("new" | "acepted")[]' is not assignable to parameter of type '[string, ...string[]]'.
z.enum<Status>(['new', 'accepted']) // Expected 2 type arguments, but got 1
z.enum(['new', 'accepted'] as [Status, ...Status[]]) // works, but ugly
z.enum(['new', 'accepted'] satisfies [Status, ...Status[]]) // works, but ugly
z.enum(['new', 'accepted'] as const satisfies readonly Status[]) // works, but could it be simpler?

at least a built-in helper would be useful:

z.enum(['new', 'accepted'] as z.EnumOptions<Status>) // self explanatory

[IlyaSemenov]

Perhaps we can update EnumValues:

zod/src/types.ts

Line 3918 in 51e14be

export type EnumValues = [string, ...string[]];

into this?

export type EnumValues<T extends string = string> = [T, ...T[]];

[IlyaSemenov]

Another option would be to update EnumValues to be less restrictive:

 export type EnumValues = string[];  // and similar updates in createEnum()

then the validation works just fine with simple satisifes test:

type Status = 'new' | 'accepted' | 'closed'

z.enum(['new', 'accepted'] satisfies Status[]) // OK
z.enum(['new', 'approved'] satisfies Status[]) // Error: Type 'string' does not satisfy the expected type 'Status[]'

In #2312, @igalklebanov told that allowing string[] was a footgun. May be it is, but I am not seeing how exactly so? After all, z.enum([]) is not a completely impossible scenario. Why would the user be disallowed to create a schema that knowingly never validates?

[IlyaSemenov]

Making EnumValues generic (see linked PR) is fully backwards compatible.

From what I have discovered [string, ...string[]] seems to be currently working not only to require at least one value but also as some kind of poor-man alternative to Typescript 5.0 const generic modifier and blindly replacing it with string[] will create a regression for inferred types. Hopefully the maintainers will decide to bump to TS 5 at some point in future.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[IlyaSemenov]

There is a PR for implementing this improve which makes no harm.

[colinhacks]

Passing a generic into z.enum<>() breaks inference. Before const parameters it used to require two generics to properly infer a tuple of string literals. In Zod 4 I'll bump the minimum version to 5.0 and there will be a more convenient way to do this.

Generally speaking, you aren't supposed to start with a type then try to write a Zod schema that's compatible with it. The goal is to define your types with Zod, so it's often inconvenient to go the other direction. This is one of those cases.

In the meantime I recommend using your own Tuple helper. It's not perfect but it works.

type Status = "pending" | "fulfilled" | "rejected";
type Tuple<T extends string> = [T, ...T[]];

const myEnum: z.ZodEnum<Tuple<Status>> = z.enum([
  "pending",
  "fulfilled",
  "rejected",
]);