Zod plugins keep one schema as the source of truth for validation, docs and mocks

Five packages around Zod, each solving one integration gap

zod-plugins is a monorepo of modules that help you use Zod in places where Zod does not reach on its own, and the project describes itself in plain terms as various modules to help use Zod in all sorts of places. The split into packages is the point. @anatine/zod-openapi converts a Zod schema into an OpenAPI 3.0 SchemaObject and builds on openapi3-ts for the typings and builders. @anatine/zod-mock generates a mock object for testing, using the peer dependency faker.js to produce the fake data. @anatine/zod-nestjs provides helper tooling for using Zod inside NestJS and includes a patch for @nestjs/swagger so the schemas shown in the documentation come from @anatine/zod-openapi. @anatine/graphql-zod-validation and @anatine/graphql-codegen-zod are both GraphQL code generator plugins that generate form validation schemas from a GraphQL schema, and the documentation describes the second as an alternative codebase to the first rather than a later version of it. Each package has its own README, and each is published under the @anatine scope.

zod-openapi treats the Zod schema as the API document

The interesting problem @anatine/zod-openapi solves is duplication. A typical service validates a payload with Zod and then writes an OpenAPI document describing the same payload, and the two drift apart. This package inverts that: the Zod schema is the source, and the OpenAPI 3.0 SchemaObject is derived from it, so a change to the validation rule is a change to the documentation. The openapi3-ts dependency is what makes the output practical, since it supplies the typed builders rather than leaving the package to assemble plain objects. For a team already using Zod for request validation, the difference in approach from hand-maintaining an OpenAPI file is that there is one artefact to review instead of two that have to be kept in agreement. The cost of that approach is that anything the Zod schema cannot express is harder to document, and a schema written for runtime validation does not always describe the wire format as neatly as a hand-written specification would.

zod-mock turns a schema into test fixtures

The mock package attacks a different duplication. Writing a fixture by hand for every schema in a service is slow, and it rots the moment the schema changes. @anatine/zod-mock generates a mock object for testing directly from the Zod schema, and the data comes from the peer dependency faker.js, so the values are random but still satisfy the schema's types and constraints. The design has a clear boundary condition worth understanding before you rely on it. Because the generator works from the schema, it can only produce what the schema describes. A schema that says a field is a string will get a random string, not a realistic value from your domain, so a mock that satisfies the schema can still be useless as a test case. The package is a way to stop writing structurally invalid fixtures, not a way to get meaningful sample data. It also brings faker.js as a peer dependency rather than a bundled one, so the version of the fake data library is your choice, and the root manifest carries @faker-js/faker in the 9.x line for development.

zod-nestjs patches Swagger so the docs match the validation

@anatine/zod-nestjs is the most opinionated of the set because it touches another framework. The package provides helper tooling to use Zod in NestJS, and it ships a patch for @nestjs/swagger so that the schemas displayed by the documentation tooling are produced by @anatine/zod-openapi instead of the default NestJS schema generation. That is a meaningful difference for a NestJS service that validates with Zod: the controller decorators and the OpenAPI output describe the same object, so a DTO change does not require editing two representations. The trade-off is that you are now depending on a patch rather than on stock @nestjs/swagger behaviour, and a patch has to be re-applied or re-released when the upstream package changes. The root manifest pins the NestJS packages at 11.0.11, with @nestjs/swagger at 11.0.6, so anyone adopting the patch should check that combination rather than assuming the latest release works.

Two GraphQL codegen plugins, two codebases

The GraphQL half of the repository is the part to read carefully. @anatine/graphql-zod-validation is used with the GraphQL code generator plugin to generate form validation schemas from a GraphQL schema, and @anatine/graphql-codegen-zod does the same job as an alternative codebase. That phrasing is deliberate and worth taking at face value. These are two implementations of one idea rather than a package and its successor, so you are choosing a codebase, not a version. The difference in approach against the common alternative is the direction of generation: rather than writing validation by hand for each GraphQL input type, the schema is the input and the Zod validation schema is the output, which keeps the two definitions in step. The cost is the usual one for codegen plugins, namely that a change in the GraphQL schema now regenerates files, and a team that has never used the GraphQL code generator will need to wire it into its build before the plugin does anything useful.

Nx pipelines, jest, and a licence field that reads as unknown

The monorepo is built with Nx, and the root package.json shows the release workflow that follows from it. The scripts are jest for tests and a family of affected commands that scope work to what changed:

    "test": "jest",
    "affected:lint": "nx affected:lint",
    "affected:test": "nx affected:test",
    "affected:build": "nx affected:build",
    "affected:publish": "nx affected --target=publish",

The publish step runs per package, which is why the release list shows package-specific tags such as zod-nestjs-2.0.12 and zod-openapi-2.2.8 rather than one version for the repository. The root manifest declares version 5.0.0, license MIT and private false, and the tooling around it is conventional TypeScript: eslint and prettier configuration, jest with a preset, tsconfig.base.json, wallaby.js for running tests in the editor, codegen.yml for the GraphQL side and an nx.json. One inconsistency deserves attention. The licence field in the GitHub metadata is empty, so the platform reports the licence as unknown, while the root package.json sets license to MIT. Each published package carries its own manifest, and the licence recorded there is what a consumer sees, so check the package you actually install rather than the repository summary. On maintenance, the last push was on 2026-06-29, and the most recent tags in the list are from April 2025, so the packages are not all released on the same schedule.

Editorial conclusion

Adopt the individual package you need rather than the monorepo, and pick @anatine/zod-openapi or @anatine/zod-mock or @anatine/zod-nestjs on its own merits, because the packages have different release dates and different peer expectations. Do not adopt the GraphQL pair expecting both to be maintained in step, since the documentation describes them as two separate codebases and the newest tags in the list are from April 2025. Before you depend on any of them, check which Zod major version your project uses, confirm the peer dependency on faker.js for the mock package, and resolve the licence question, because the licence field in the GitHub metadata is empty even though the root package.json declares MIT.

Frequently asked questions

Official sources

1. anatine/zod-plugins on GitHub
2. Issues
3. README
4. Releases