Torleif Berger

I believe `type` already is included in most issues? It's just sometimes it's called something else, like for the `invalid_type` issue where it's called `expected` instead.

Yeah, I'm not sure what would be best here. I don't even require the `type` myself really, I just want a way to label stuff. For my issue #1208, it...

I already check for type within each code, so that's not an issue for me. My current error map looks like this, and I find it fairly clean actually: ```ts...

@colinhacks > I seems like adding a `label` property and passing it into error maps is an unnecessary layer of indirection. Same for `description`, which I only grudgingly added to...

A workaround, if others run into this before it hopefully gets improved: ```ts case ZodIssueCode.invalid_type: switch (issue.expected) { // ... } if (/^(?:'(\w+)'(?: \| )?)+$/.test(issue.expected)) { return 'must be selected';...

If it's required to have a specific set of keys, then it's not really a "record", I would say. `z.object` is the correct thing to use. To create consistent schemas...

@scotttrinh That makes sense, but does `transform` happen before or after validation? I can for example transform into `NaN` if the value is `null`, but would the validation happen "on"...

As for the `react-hook-form` part of it, I asked a question in their repo for that. Basically, their `useForm` only accepts a single generic for their `TFieldValues`, which is used...

Reading your flow diagram, it then seems that `null` would actually get through all of validation, without being stopped anywhere, and finally be transformed to `NaN`, which would then be...

Yeah, just confirmed it. `.nullable()` allows `null` to get through, which I guess I should've expected. But then I'm even less sure how to actually allow `null` type-wise, but not...