new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Zod · all subjects

ecosystem integrations

14 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Ecosystem section focuses on Zod 4 libraries

The Ecosystem section of the Zod documentation focuses on libraries that support Zod 4. For libraries that work with Zod 3, refer to v3.zod.dev.

Zod ecosystem categories

Zod has a thriving ecosystem organized into categories: Resources, API Libraries, Form Integrations, Zod to X, X to Zod, Mocking Libraries, and Powered by Zod.

Recommended ecosystem projects by creator

Colin McDonnell (creator of Zod) recommends tRPC for end-to-end typesafe APIs with Zod schema support, React Hook Form for hook-based form validation with Zod resolver support, and zshy as a bundler-free build tool for TypeScript libraries.

Zod 3 end-of-life status

Zod 3 is functionally end-of-life. It still receives security fixes and unambiguous bug fixes, but no new features will land on zod@3.x. For any new library or any new major version of an existing library, target Zod 4 only.

When to use Standard Schema instead of Zod

If you are building a library that accepts user-defined schemas to perform black-box validation, consider using Standard Schema instead of depending directly on Zod. Standard Schema is a shared interface implemented by most popular validation libraries in the TypeScript ecosystem, including Zod. It works well when you accept user-defined schemas and treat them as black-box validators—you can extract inferred input/output types, validate inputs, and get a standardized error.

Library peer dependencies for Zod 4

Any library built on top of Zod should include "zod" in "peerDependencies" with "^4.0.0" to let users bring their own Zod. During development, add "zod" to "devDependencies" as well to meet your own peer dependency requirement.

Import subpath for Zod 4 core

Library authors should import the Zod 4 core package from the "zod/v4/core" subpath using `import * as z4 from "zod/v4/core"`. This subpath is a permalink to Zod 4 that will remain available forever, even across future major versions of the zod package.

Subpaths to avoid importing from

Do not import from "zod", "zod/v4", or "zod/v4/mini". The "zod" path changes between major versions. The "zod/v4" and "zod/v4/mini" paths are specific to Zod Classic and Mini respectively. If you reference classes from these paths, your library will not work with both Zod and Zod Mini. Always use "zod/v4/core" instead, which exports the $-prefixed subclasses that are extended by both Zod Classic and Zod Mini.

Dual support for Zod 3 and Zod 4

To extend an existing library to support both Zod 3 and Zod 4 users, widen your peer dependency to "^3.25.0 || ^4.0.0" (the "zod/v4" subpath is available starting in 3.25.0). You can import both side by side using `import * as z3 from "zod/v3"` and `import * as z4 from "zod/v4/core"`. To differentiate between Zod 3 and Zod 4 schemas at runtime, check for the "_zod" property, which is only defined on Zod 4 schemas.

Supporting Zod and Zod Mini simultaneously

To support both Zod and Zod Mini simultaneously, library code should only import from "zod/v4/core". This sub-package defines the interfaces, classes, and utilities shared between Zod and Zod Mini. As long as you follow this rule, both Zod and Zod Mini will work automatically. Build your generic constraints against the shared base interfaces (like z4.$ZodType and z4.$ZodObject) rather than specific implementations.

Generic constraints for accepting schemas

When accepting user-defined schemas in a library function, use generic constraints that extend z4.$ZodType rather than specifying a concrete type. For example, use `function acceptSchema<T extends z4.$ZodType>(schema: T)` instead of `function acceptSchema<T>(schema: z4.$ZodType<T>)`. The first approach preserves the specific subclass type (like ZodString), allowing you to call subclass-specific methods on the result. The second approach loses type information and only returns the base z4.$ZodType.

Constraining schemas by type or output

Use generic constraints to limit which schemas your function accepts. To accept only object schemas: `function acceptSchema<T extends z4.$ZodObject>(schema: T)`. To accept only string schemas: `function acceptSchema<T extends z4.$ZodType<string>>(schema: T)`. These constraints allow you to build type-safe library functions that work with specific schema types.

Parsing data with Zod Core

To parse data with a schema in library code, use the top-level z4.parse, z4.safeParse, z4.parseAsync, or z4.safeParseAsync functions from zod/v4/core. The z4.$ZodType subclass has no parsing methods on it—parsing methods are implemented by Zod and Zod Mini but are not available in Zod Core.

zod/v4/core is extensible foundation for schema libraries

zod/v4/core is a sub-package containing core functionality shared between Zod and Zod Mini. Schema library authors can build on this foundation as demonstrated by Zod and Zod Mini implementations.

Give your agent this brain