Colin McDonnell

This is interesting but not worth the squeeze, in my opinion. We need to be conservative about what sorts of features make it into core as Zod gets larger, and...

There are a lot of ways to solve this, as others have stated. My preferred solution is probably something like this: ```ts z.union([z.literal("").transform(() => null), z.string().datetime()]).nullish(); ``` --- But ultimately...

It's true. Zod is going to have to implement a `ZodRequired` subtype so `.required()` behaves more reasonably. Hopefully next version.

In your examples, the type is not being inferred or extracted from a self-referencing runtime construct. It's trivially easy to write a recursive type. I didn't fully follow your code...

I'm opposed to changing from the existing implementation that uses `URL` - Zod should fall back on JavaScript built-ins whenever possible imo

I like a lot of these ideas, but this is a big API surface with a lot of potential headaches. Some open questions: Will `.pathname()`, `.user()`, `.password()` etc. support regexes?...

Small correction - `z.string().datetime()` still returns a string, not a `Date`. I'm in favor of adding `.date()` and `.time()` methods for convenience, though using `.regex` for these is pretty straightforward...

Good call, just added some docs to this effect. This decision is discussed in slightly more detail at https://github.com/colinhacks/zod/issues/1630

I export literally everything from types.ts so people have an easier time building things on top of Zod. The downside is that there is virtually no change I can make...

It's not worth the disruption to users in my opinion. 98% of users don't know enough about Zod internals to understand the "breakages" even if I explained them, even with...