# Zod Admin & Architecture Guide

This guide is for the audience that needs to understand Zod from the inside: library authors integrating Zod into their own tooling, contributors working on the codebase, and architects evaluating Zod's design, performance characteristics, and security posture. It documents the monorepo layout, the internal engine, the build and release pipeline, and the contribution workflow — all derived from the source at the documented commit.

> [!NOTE]
> This guide covers **Zod 4** (`zod@4.4.3`). For end-user, schema-authoring documentation (defining schemas, parsing, error handling), see the companion User Guide.

---

## Table of Contents

1. [Executive Summary](#1-executive-summary)
2. [Repository Architecture](#2-repository-architecture)
3. [The Validation Engine](#3-the-validation-engine)
4. [Package Layout & Export Map](#4-package-layout--export-map)
5. [Build, Test & Release Pipeline](#5-build-test--release-pipeline)
6. [Performance](#6-performance)
7. [Security Analysis](#7-security-analysis)
8. [Versioning Strategy](#8-versioning-strategy)
9. [Operations: Integrating Zod as a Library Author](#9-operations-integrating-zod-as-a-library-author)
10. [Code Quality & Conventions](#10-code-quality--conventions)
11. [Potential Improvements](#11-potential-improvements)
12. [Contributing](#12-contributing)
13. [Quick Reference](#13-quick-reference)

---

## 1. Executive Summary

Zod is a **TypeScript-first schema declaration and validation library with static type inference**. Its defining idea is that a single schema declaration yields both a runtime validator and a static type, eliminating the drift between the two that plagues hand-maintained type definitions.

| Attribute | Value |
|---|---|
| Package name | `zod` |
| Version (documented) | `4.4.3` |
| License | MIT |
| Author | Colin McDonnell |
| Runtime dependencies | **Zero** |
| Language | TypeScript (`~5.5.4`) |
| Module formats | ESM + CommonJS (dual build) |
| Repository style | pnpm monorepo (`pnpm@10.12.1`) |
| Distribution | npm + JSR (`@zod/zod`) |
| `sideEffects` | `false` (fully tree-shakable) |

Architecturally, Zod 4 is layered: a **core engine** (`v4/core`) does all the real work, and two thin API surfaces sit on top of it — **classic** (chainable methods, `import "zod"`) and **mini** (composable functions, `import "zod/mini"`). The previous major version is preserved verbatim as **v3** for incremental migration. This layering is the single most important fact for anyone working on or deeply integrating Zod.

```
                ┌──────────────┐   ┌──────────────┐
   import "zod" │   classic    │   │     mini     │ import "zod/mini"
                │ (chained API)│   │ (functional) │
                └──────┬───────┘   └──────┬───────┘
                       │                  │
                       └────────┬─────────┘
                                ▼
                        ┌───────────────┐
                        │   v4/core     │  the engine:
                        │  schemas,     │  parse, checks, errors,
                        │  parse, errors│  registries, JSON Schema
                        └───────────────┘
```

---

## 2. Repository Architecture

Zod is developed as a **pnpm workspace monorepo**. The published library is a single package (`packages/zod`); the other packages are private tooling that never ships to npm.

| Package | npm name | Private? | Purpose |
|---|---|---|---|
| `packages/zod` | `zod` | Published | The library itself — the only public artifact. |
| `packages/bench` | `@zod/benchmarks` | Yes | Runtime benchmarks (vs. arktype, valibot, and older Zod). |
| `packages/tsc` | `@zod/tsc-perftest` | Yes | **Type-checking** performance tests — measures `tsc` instantiation cost. |
| `packages/treeshake` | `@zod/treeshaking` | Yes | Verifies bundle output is tree-shakable (Rollup/esbuild). |
| `packages/resolution` | `@zod/resolution` | Yes | Tests that every export resolves correctly across module systems (CJS/ESM/NodeNext). |
| `packages/docs` | `@zod/docs` | Yes | The `zod.dev` documentation site (Next.js + Fumadocs). |
| `packages/integration` | `@zod/integration` | Yes | Integration fixtures (Vercel AI SDK, drizzle-zod) guarding against "type instantiation excessively deep" regressions. |

> [!IMPORTANT]
> Only `packages/zod` is published. When contributing, the source of truth for the library lives entirely under `packages/zod/src/`. The other packages exist to *measure and protect* the library — its bundle size, its type-check cost, its module resolution, and its compatibility with downstream tools.

### Inside `packages/zod/src/`

```
packages/zod/src/
├── index.ts            → re-exports v4/classic (this is `import "zod"`)
├── mini/index.ts       → re-exports v4/mini
├── locales/index.ts    → re-exports v4/locales
├── v3/                 → the complete, frozen Zod 3 codebase
└── v4/
    ├── core/           → THE ENGINE (schemas, parse, errors, checks, …)
    ├── classic/        → chainable method API on top of core
    ├── mini/           → functional API on top of core
    └── locales/        → 50+ translated error-message maps
```

The root `index.ts` is deliberately tiny:

```ts
import * as z from "./v4/classic/external.js";
export * from "./v4/classic/external.js";
export { z };
export default z;
```

This means `import { z } from "zod"` and `import "zod"` both resolve to the **classic v4** surface.

---

## 3. The Validation Engine

Everything substantive happens in `packages/zod/src/v4/core/`. Understanding these modules is the key to understanding (and contributing to) Zod.

| Module | Responsibility |
|---|---|
| `core.ts` | The `$constructor` trait system, global config, type helpers (`input`, `output`, `infer`), branding. |
| `schemas.ts` | All `$Zod*` schema classes (the largest file — the type definitions and run logic for every schema). |
| `checks.ts` | All `$ZodCheck*` classes (min, max, length, regex, multipleOf, …). |
| `api.ts` | The factory functions (`_string`, `_number`, `_object`, …) that classic/mini wrap. |
| `parse.ts` | `parse`, `safeParse`, async variants, and the codec `encode`/`decode` family. |
| `errors.ts` | The issue type union, `$ZodError`, and formatters (`flattenError`, `formatError`, `treeifyError`, `prettifyError`). |
| `registries.ts` | The metadata registry system and the global registry. |
| `to-json-schema.ts` + `json-schema-*.ts` | JSON Schema generation. |
| `regexes.ts` | The regular expressions behind every string format. |
| `doc.ts` | The JIT compiler (`Doc` class) that builds optimized validators. |
| `standard-schema.ts` | Implements the [Standard Schema](https://standardschema.dev) spec for cross-library interop. |
| `config.ts` / `util.ts` / `versions.ts` | Global config, shared utilities, version constants. |

### The `$constructor` trait system

Zod does **not** use conventional `class extends` inheritance for its schemas. Instead, `core.ts` defines a `$constructor` factory that builds objects with a **trait set** stored on a non-enumerable `_zod` property:

```ts
export function $constructor(name, initializer, params?) {
  function init(inst, def) {
    if (!inst._zod) {
      Object.defineProperty(inst, "_zod", {
        value: { def, constr: _, traits: new Set() },
        enumerable: false,
      });
    }
    if (inst._zod.traits.has(name)) return;
    inst._zod.traits.add(name);
    initializer(inst, def);
    // copy bound prototype methods onto the instance
  }
  // ...
}
```

Two consequences worth knowing:

- **`instanceof` is trait-based.** `$constructor` overrides `Symbol.hasInstance` to check `inst._zod.traits.has(name)`, so `x instanceof z.ZodString` works by trait membership rather than prototype chains. This is what allows a schema to satisfy multiple "is-a" relationships and survive across module boundaries.
- **Internals live on `_zod`.** Every schema's definition, input/output types, parent pointer, and run function are under the non-enumerable `_zod` namespace, keeping the public surface clean.

> [!NOTE]
> The `_zod` property is non-enumerable by design — it will not show up in `Object.keys()`, `JSON.stringify()`, or spreads. Treat it as private engine state; the supported public surface is the documented methods and factory functions.

### Global state on `globalThis`

Both the global config and the global metadata registry are attached to `globalThis` (`__zod_globalConfig`, `__zod_globalRegistry`):

```ts
(globalThis as any).__zod_globalRegistry ??= registry<GlobalMeta>();
export const globalRegistry = (globalThis as any).__zod_globalRegistry;
```

This deliberately defends against the **dual-package hazard**: if two copies of Zod load (one via `require`, one via `import`, or duplicated across a monorepo's bundles), they still share one config object and one registry. A `z.config({...})` applied to any instance is observed by all of them.

> [!TIP]
> Because config lives on `globalThis`, you can pre-seed it *before Zod loads* — e.g. an inline `<script>` setting `globalThis.__zod_globalConfig = { jitless: true }` takes effect the moment Zod is imported. This is useful for CSP-restricted environments (see [Security](#7-security-analysis)).

### Issue model

`errors.ts` defines a closed union of issue shapes, each tagged by a `code`:

| `code` | Carries |
|---|---|
| `invalid_type` | `expected` type. |
| `too_big` / `too_small` | `origin`, `maximum`/`minimum`, `inclusive`, `exact`. |
| `invalid_format` | `format`, optional `pattern`. |
| `not_multiple_of` | `divisor`. |
| `unrecognized_keys` | `keys[]`. |
| `invalid_union` | nested `errors[][]`, optional `discriminator`. |
| `invalid_key` / `invalid_element` | `origin` (`map`/`record`/`set`), nested `issues`. |
| `invalid_value` | allowed `values[]`. |
| `custom` | optional `params`. |

Raw issues are "finalized" through `util.finalizeIssue` during parse, which applies the error-map precedence (schema-level → global custom → locale) before the `$ZodError` is constructed.

---

## 4. Package Layout & Export Map

The published package exposes a carefully curated set of subpath exports. The authoritative source is the `exports` field in `packages/zod/package.json`:

| Subpath | Maps to | Audience |
|---|---|---|
| `.` (`zod`) | `v4/classic` | Everyone — the default. |
| `./mini` | `v4/mini` | Bundle-size-sensitive apps. |
| `./v3` | `v3` | Teams migrating from Zod 3. |
| `./v4` | `v4/classic` | Explicit v4 pin. |
| `./v4-mini`, `./v4/mini` | `v4/mini` | Explicit mini pin. |
| `./v4/core` | `v4/core` | **Library authors** building on the engine. |
| `./locales`, `./v4/locales`, `./v4/locales/*` | locale maps | i18n. |

Every subpath declares three conditions — `@zod/source` (raw TS, used internally during development via `tsx --conditions @zod/source`), `import` (ESM build), and `require` (CJS build) — plus matching `.d.ts`/`.d.cts` type declarations. This triple-condition setup is what makes Zod work identically under ESM, CommonJS, bundlers, and `skipLibCheck: false`.

> [!IMPORTANT]
> If you are a **library author** who accepts user-supplied Zod schemas, import from `zod/v4/core` and program against the `$ZodType` interface rather than the concrete classic classes. This keeps your library compatible with both classic and mini schemas, and insulates you from classic-API surface changes. The companion `library-authors` documentation on zod.dev covers the generic-function patterns (`how-to-accept-user-defined-schemas`).

The package is also published to **JSR** as `@zod/zod` (`packages/zod/jsr.json`), with one export entry per locale so Deno users can import individual languages.

---

## 5. Build, Test & Release Pipeline

Zod uses a modern, fast TypeScript toolchain. No webpack, no Babel.

| Concern | Tool |
|---|---|
| Package manager | `pnpm@10.12.1` (workspace) |
| Build | **`zshy`** — a zero-config, bundler-free TS→JS/d.ts build. |
| Lint & format | **Biome** (`biome check`, `biome lint`). |
| Tests | **Vitest** (`vitest run`), including `expectTypeOf` type-level assertions. |
| Dev runner | `tsx` with `--conditions @zod/source` (runs raw source, no build step). |
| Bundlers (for treeshake tests) | Rollup, esbuild, rolldown, tsdown. |
| Pre-commit | Husky + lint-staged (Biome on `.ts`/`.json`, Prettier on `.md`). |

### Key scripts (root `package.json`)

```bash
pnpm build          # build the zod package via zshy
pnpm test           # vitest run (all packages)
pnpm test:watch     # vitest in watch mode
pnpm dev            # tsx --conditions @zod/source (run source directly)
pnpm bench          # run runtime benchmarks
pnpm format         # biome check --write .
pnpm lint           # biome lint --write .
pnpm check:circular # madge — detect circular imports
pnpm check:semver   # verify version consistency before publish
```

### The `@zod/source` condition

The most distinctive workflow detail: during development, code runs **directly from TypeScript source** with no build. Internal tooling (tests, benchmarks, integration fixtures) sets the custom module condition `@zod/source`, which the `exports` map resolves to the raw `./src/*.ts` files. This gives instant feedback loops — edit a file and `pnpm test` sees the change with no rebuild.

### Release gates

`prepublishOnly` runs `check-versions.ts` (and at the root, the full test + build), so a publish cannot proceed if versions are inconsistent or tests fail.

> [!NOTE]
> `packages/zod/src/v4/core/versions.ts` holds the version constants embedded into the runtime. `pnpm check:semver` cross-checks these against `package.json` to prevent a mismatched release.

---

## 6. Performance

Performance is a first-class design goal in Zod 4, attacked on two fronts: **runtime parse speed** and **TypeScript compiler cost**. The repo dedicates entire packages to measuring each.

### Runtime: JIT-compiled validators

The `Doc` class in `core/doc.ts` is a small code generator. For hot schemas, Zod assembles validator logic as a string and compiles it with the `Function` constructor:

```ts
class Doc {
  compile() {
    const F = Function;
    const lines = this.content.map((x) => `  ${x}`);
    return new F(...this.args, lines.join("\n"));
  }
}
```

A compiled, specialized function avoids the interpretation overhead of walking the schema tree on every parse. This JIT step is the main reason Zod 4 is substantially faster than Zod 3 on repeated validation.

`packages/bench` benchmarks this against `arktype`, `valibot`, and older Zod versions using `mitata`, `tinybench`, and `benchmark.js` (selectable via the `BENCH` environment variable).

### Tree-shaking

The package sets `"sideEffects": false`, and nearly every factory function is annotated `@__NO_SIDE_EFFECTS__` / `@__PURE__`. This lets bundlers eliminate unused schema types. `packages/treeshake` exists solely to verify, via Rollup and esbuild, that importing one schema does not pull in the whole library — and Zod Mini exists for cases where even the classic API's chaining is too much.

### Type-check cost

`packages/tsc` measures how expensive Zod's types are for `tsc` to instantiate — a real concern for a library whose types are this rich. `@typescript/analyze-trace` profiles instantiation depth. The `packages/integration` fixtures specifically guard against the dreaded **"Type instantiation is excessively deep and possibly infinite"** error when Zod is combined with heavy downstream generics (Vercel AI SDK, drizzle-zod).

> [!CAUTION]
> Deeply nested or heavily generic schemas can still strain `tsc`. If you hit "excessively deep" errors when combining Zod with another type-heavy library, check whether that library has a Zod-4-compatible release — the integration fixtures in this repo track exactly those known-bad combinations and their fixes.

---

## 7. Security Analysis

Zod's attack surface is small — it has no network, filesystem, or process access and zero dependencies — but there are real considerations for the contexts it runs in.

### `eval` / CSP (`unsafe-eval`)

The JIT compiler uses the `Function` constructor, which a strict **Content Security Policy** treats as `eval` and may block. This surfaces as a CSP `unsafe-eval` violation (community issue #4461), particularly in browser extensions and locked-down web apps.

**Mitigation:** Zod provides a `jitless` config flag that disables compilation entirely, falling back to interpreted validation:

```ts
z.config({ jitless: true });
// or, before Zod loads:
// globalThis.__zod_globalConfig = { jitless: true }
```

> [!WARNING]
> In any environment that forbids `unsafe-eval`, set `jitless: true` **before** schemas are constructed. There is a runtime cost (interpreted parsing is slower than JIT), but it is the correct trade-off where CSP forbids dynamic code generation.

### Input-driven resource use (ReDoS)

Zod validates many string formats with regular expressions (`core/regexes.ts`). Catastrophic-backtracking regexes are a denial-of-service vector for any regex-driven validator. The repo's dev dependency on **`recheck`** (a ReDoS static analyzer) indicates the maintainers screen the built-in patterns for vulnerable constructs.

> [!TIP]
> When you add a **custom** `z.string().regex(...)`, you are responsible for its safety. Audit user-influenced patterns for catastrophic backtracking, and prefer anchored, possessive-style constructions. Zod vets its own built-in formats, not yours.

### Prototype pollution

Object parsing uses internal helpers (`isPlainObject`, `shallowClone`) that are explicitly tested against malicious `constructor` keys (see the v4 classic test suite). `isPlainObject` accepts objects whose `constructor` field is an arbitrary value, and `shallowClone` preserves such fields without invoking them — guarding against prototype-pollution-style payloads being mishandled during validation.

### Trust boundary

Zod is a **validation** tool: its job is to be the trust boundary. The recommended pattern is to `safeParse` all external input (request bodies, query params, env vars, third-party API responses) at the edge of your system and propagate only typed, validated data inward. Parsing does not sanitize for injection — it confirms shape and type; downstream encoding/escaping remains your responsibility.

---

## 8. Versioning Strategy

Zod's most unusual operational characteristic is that **multiple major versions ship inside one package**.

<a id="version-map"></a>

| You import | You get | Notes |
|---|---|---|
| `zod` | Zod 4 classic | The default and recommended surface. |
| `zod/v4` | Zod 4 classic | Explicit, identical to `zod`. |
| `zod/mini`, `zod/v4/mini` | Zod 4 mini | Same engine, functional API. |
| `zod/v3` | Zod 3 | The full, frozen Zod 3 source — bug-for-bug compatible. |

The `v3/` directory is a complete copy of the prior major version, preserved so teams can migrate **file by file**: change `import { z } from "zod"` to `import { z } from "zod/v3"` in modules not yet ported, then move them to v4 incrementally. This eliminates the all-or-nothing upgrade cliff typical of major version bumps.

The runtime version is exposed through `core/versions.ts` and stamped at publish time; `pnpm check:semver` enforces consistency.

> [!NOTE]
> Zod 4 also formally implements the [Standard Schema](https://standardschema.dev) interface (`core/standard-schema.ts`), a shared spec that lets validation libraries (Zod, Valibot, ArkType) be used interchangeably by downstream tools like tRPC and the Vercel AI SDK. If you build tooling, target `StandardSchemaV1` to accept schemas from any compliant library.

---

## 9. Operations: Integrating Zod as a Library Author

If you are embedding Zod into your own framework or tool (rather than just using it to validate data), follow these practices drawn from the codebase's own conventions.

### Accept schemas via the core interface

```ts
import type { $ZodType, infer as zInfer } from "zod/v4/core";

function makeEndpoint<S extends $ZodType>(schema: S) {
  return (input: unknown): zInfer<S> => {
    // validate with the engine
  };
}
```

Programming against `$ZodType` (not `ZodString`/`ZodObject`) accepts **both** classic and mini schemas and survives API evolution.

### Prefer Standard Schema for cross-library interop

If your tool should accept schemas from Zod *or* other libraries, target `StandardSchemaV1` instead of any Zod-specific type. Zod schemas satisfy it automatically.

### Respect global config

Do not reach into `_zod` internals or mutate the global registry behind the user's back. If you need per-call behavior, thread it through the documented parse context rather than the global config, which the user owns.

### Reading metadata

To surface descriptions/titles (e.g. for generated docs or forms), read from `z.globalRegistry` or accept a user-provided registry. Remember that `get()` inherits parent metadata but never inherits `id`.

---

## 10. Code Quality & Conventions

| Convention | Detail |
|---|---|
| **Formatting** | Biome, enforced on every commit via lint-staged. |
| **Naming** | Internal engine types are prefixed `$Zod` (e.g. `$ZodString`, `$ZodCheck`, `$ZodError`); public classic types drop the `$` (`ZodString`). |
| **Privacy** | All engine state hidden behind a non-enumerable `_zod` property. |
| **Purity** | Factories marked `@__NO_SIDE_EFFECTS__`; package is `sideEffects: false`. |
| **No circular deps** | Enforced by `madge --circular` in CI (excluding the v4/core and v3 internals). |
| **Type-level tests** | Vitest `expectTypeOf` assertions run alongside runtime tests — types are tested, not just code. |
| **Error-message parity** | A docs test (`packages/docs/content/api.test.ts`) asserts that Zod and Zod Mini tabbed code examples stay in lockstep. |

The codebase favors small, composable functions and a strict separation between the engine (`core`) and the user-facing wrappers (`classic`, `mini`). New schema types are added by defining a `$Zod*` class in `core/schemas.ts`, a factory in `core/api.ts`, and then exposing it through both the classic and mini surfaces.

---

## 11. Potential Improvements

These are drawn directly from open community issues and observable gaps at the documented commit. They represent the live edges of the project.

| Area | Observation | Source |
|---|---|---|
| **Abort-early mode** | No first-class way to stop validation at the first error; a long-standing, highly-commented request. | Issue #3884 |
| **Tree-shaking of locales** | `zod/v4/classic` can pull in *all* locale files because of a non-tree-shakable `export * as locales`, inflating bundles. | Issue #6050 |
| **JSON Schema fidelity** | `toJSONSchema` drops `default` when the defaulted schema contains a transform/pipe; union compaction and number-format distinctions are also requested. | Issues #6049, #6047, #6045 |
| **JSDoc propagation** | `@deprecated` JSDoc tags are not propagated to generated types/metadata. | Issue #6038 |
| **Non-type-transforming mutation** | No supported way to mutate input without changing the inferred type. | Issue #6011 |
| **Documentation gaps** | Several APIs (`z.string().nonempty()`, regex usage, schemas-as-parameters) are under-documented; v3 docs return 404s. | Issues #6055, #6058, #6060, #6009 |

> [!NOTE]
> Issue #3884 (abort-early) is worth singling out: today Zod collects *all* issues by default. For large objects on a failure path, that means doing work for fields the caller may not care about. Benchmark idea #6046 proposes measuring exactly this failure-path cost — a signal the maintainers are actively profiling it.

---

## 12. Contributing

The repository is set up for a fast, low-friction contribution loop.

**Setup:**

```bash
pnpm install           # install workspace dependencies
pnpm dev play.ts       # scratch-pad: run source directly via tsx
```

**Make a change:**

1. Edit source under `packages/zod/src/v4/`. New schema types touch `core/schemas.ts`, `core/api.ts`, and both `classic/` and `mini/` surfaces.
2. Add tests in the relevant `tests/` directory — include `expectTypeOf` assertions for type-level behavior, not just runtime.
3. Run the suite:

```bash
pnpm test              # vitest run
pnpm check:circular    # ensure no new circular imports
pnpm format            # biome
```

**Before opening a PR — verification checklist:**

- [ ] `pnpm test` passes (runtime **and** type assertions).
- [ ] `pnpm check:circular` reports no new cycles.
- [ ] `pnpm format` and `pnpm lint` are clean (also enforced by the Husky pre-commit hook).
- [ ] If you touched the public API, the classic and mini surfaces stay in parity (the docs `api.test.ts` parity test will catch tabbed-example drift).
- [ ] If you changed string-format regexes, consider a `recheck` pass for ReDoS safety.

> [!TIP]
> Use `pnpm dev play.ts` as a scratch pad. Because dev mode runs raw source through `tsx --conditions @zod/source`, you get an instant edit-run loop with no build step — the fastest way to reproduce a bug or prototype a feature.

---

## 13. Quick Reference

### Source map (where things live)

| To change… | Edit… |
|---|---|
| A schema's validation logic | `packages/zod/src/v4/core/schemas.ts` |
| A check (min/max/regex/…) | `packages/zod/src/v4/core/checks.ts` |
| The public factory signature | `packages/zod/src/v4/core/api.ts` |
| Parse/encode/decode behavior | `packages/zod/src/v4/core/parse.ts` |
| Error shapes & formatters | `packages/zod/src/v4/core/errors.ts` |
| JSON Schema output | `packages/zod/src/v4/core/to-json-schema.ts`, `json-schema-*.ts` |
| A string-format regex | `packages/zod/src/v4/core/regexes.ts` |
| The JIT compiler | `packages/zod/src/v4/core/doc.ts` |
| Error translations | `packages/zod/src/v4/locales/*.ts` |
| The classic chained API | `packages/zod/src/v4/classic/` |
| The mini functional API | `packages/zod/src/v4/mini/` |

### Commands

| Command | Action |
|---|---|
| `pnpm build` | Build via zshy. |
| `pnpm test` / `pnpm test:watch` | Run / watch Vitest. |
| `pnpm dev [file]` | Run TS source directly. |
| `pnpm bench` | Runtime benchmarks. |
| `pnpm format` / `pnpm lint` | Biome format / lint. |
| `pnpm check:circular` | Detect circular imports (madge). |
| `pnpm check:semver` | Validate version consistency. |

### Configuration knobs (`z.config`)

| Option | Effect |
|---|---|
| `customError` | A custom error map (highest priority). |
| `localeError` | A locale error map (lowest priority). |
| `jitless` | Disable JIT compilation (for CSP/`eval`-restricted environments). |

### Engine type interfaces (from `zod/v4/core`)

| Type | Use |
|---|---|
| `$ZodType` | Accept any Zod schema (classic or mini). |
| `$ZodCheck` | A validation check. |
| `$ZodError`, `$ZodIssue` | Error and issue shapes. |
| `StandardSchemaV1` | Cross-library schema interop. |
| `infer`, `input`, `output` | Type extraction helpers. |

---

_Generated June 2026 from colinhacks/zod at bbc68f9. AI-generated documentation. The library is checked by sampling (three repositories so far); this guide was not individually reviewed. Verify against the project before relying on it. Unofficial; not affiliated with or reviewed by the project._