Useful or not, from you.
zod Docs on integrating with other OSS

It would be nice to have docs on how to integrate zod with other OSS. This would help people:

  • identify whether zod will work well with their tech stack
  • figure out how to use zod with their tech stack
  • help zod validate its feature set. If the docs are hard to write, zod is probably missing something.


It seems like zod could be well suited for GraphQL validations. It would be handy to have a reference for the parallels of GraphQL types and their corresponding zod types, as well as any other suggestions for integrating zod into the GraphQL environment.

As a single small example:

union Fish = Salmon | Tuna | Trout
type Catch {
  fish: Fish!
const FishEnum = z.union([z.literal('Salmon'), z.literal('Tuna'), z.literal('Trout')]);
const Catch = z.object({
  fish: FishEnum,

Of course it's a bit less obvious when it comes to nullable types because GraphQL is nullable by default, and zod is required by default.

React PropTypes

Seems like an integration that would make sense for libraries. Similar docs like those for GraphQL could make sense.


Formik has native support for Yup schemas. Docs on integrating zod with formik would be nice!

That's a useful answer
Without any help

I am not using Formik + zod, but I am trying to establish what these integrations would look like before really investing in the stack. So, "not yet" is the short answer. I'm also not necessarily sold on either component just yet, since I'm trying to evaluate all the components together before making decisions.

I made a library some time ago with the main idea that it would be a single place to define the structure of objects. It was designed to be a pluggable system that allowed for modular integrations with various functions. It's old and crusty now, there are flaws in the design, it wouldn't play nicely with TS, and I don't actually use it for anything, but there may be some ideas worth taking a look at.

Library: GraphQL integration module: Other modules, like PropTypes:

From a high level, a takeaway I had from building that was that if you create a single core schema with a number of tools coming out of it, you're bound to the lowest-common-denominator of functionality across the systems. e.g. if a module doesn't support unions, you can't have unions in any part of the schema unless you have a way of failing over to something that does something similar enough to unions to be compatible.