.keyof

I have an enum mapping an external status string to an internal status string:

enum STATUS_MAP {
  pending = internal.Pending,
  engaged = internal.Pending,
  pickup_confirmed = internal.Pending,
  canceled = internal.Cancelled,
  on_route = internal.Pending,
  on_delivery = internal.Shipped,
  delivered_recipients_here = internal.Delivered,
  delivered_recipients_not_here = internal.Delivered,
}

If I understand correctly there is no combinator out of the box that takes this enum and returns a schema for the keys (pending, engaged, etc.) Am I correct?

If so, I’ll try to implement such a combinator and submit it as a PR this week-end.

[carlpaten]

That’s one approach! But if I understand correctly, methods on schema objects are usually handy refinements, while this would be (conceptually, and probably implementation-wise too) a new primitive. Accordingly, I thought this would be neat as a method on the top-level object.

Here’s my proposal:

1. z.keyof(myEnum) should infer a type equivalent to keyof typeof myEnum.
2. z.keyof should take any Record, or subtype thereof (worst case scenario it infers string or string | number or whatever).
3. At runtime, it behaves just like ZodEnum.

In an ideal world we wouldn’t need this primitive, it would just be done via z.enum(Object.keys(myEnum). However Object.keys returns not keyof typeof myEnum but string[]. This is because some objects have more keys than is known at compile-time.. I claim that this issue is not likely to be encountered in Zod, but if you disagree then I’m happy to table that and look for ways to only work with/support native enums.

[carlpaten]

My apologies, I wrote this first thing in the morning and it looks like I hadn’t completely woken up. I looked at your example and I understand exactly what you mean. I think your best bet is a call to refine on the top-level object, i.e. the one that contains both the record and the key-valued fields.

I would tentatively advocate against adding a combinator addressing this particular use case to the core Zod library. The issue is that this is a kind of validation that’s both non-local (the result can depend on the value of another field that can be arbitrarily far) and dynamic (the specific validity conditions aren’t known until runtime). This would make it very difficult to report clear errors. It’s also difficult for me to conceive of a “best” design that would cleanly address this and related use cases; the more likely result is a proliferation of special-case combinators, which is something we’re trying to avoid.