Zod Progress

[vitalics]

As a part of this issue, we need to propose a way to compatibility of zod API.

issue motivated from #32

here is a list of features that zod has:

• superRefine
• custom errors #54
• void, undefined, function, Set, Map, NaN - possibly it's never be released, since it is not a part of JSON-schema standard - expose empty functions?
• custom types (aka, z.custom)
• expose literal as const since it's the same #41
• expose date as string().date()
• z.string - datetime, it's parameters
• expose nativeEnum as a part of the enum (we already handle it, just expose) #38
• expose schema with name shape(zod exposes shape instead of schema) #43
• s.deepPartial need to research
• z.strip
• z.catchall
• z.array.element #46
• z.nullish - research
• z.lazy - need to research
• expose transform function
• expose z.ZodType<T> type
• z.promise - uses $async schema?
• z.instanceOf - research
• z.preprocess port to s.preprocess
• expose z.parseAsync
• refine compatibility
• expose z.catch
• expose z.brand
• expose z.pipe

Add comments if I missed something

[miguelrk]

As an additional note, I see 2 alternative ways of doing this:

1. aliasing: adding the extra props to the current API (e.g. adding literal and shape alongside const and schema)
2. refactoring: renaming duplicate fields to their zod counterparts and exposing them exclusively (e.g. const -> literal, schema -> shape

Both approaches would work, just thought it might be good on deciding on one before pursuing this refactor 👍🏼

[vitalics]

I like aliasing since current implementations are pretty close to JSON-schema naming.