zod-compiler 1.22.0 → 1.22.2

package/README.md

@@ -2,7 +2,7 @@
 
 **Compile Zod schemas into zero-overhead validation functions at build time.**
 
-Keep your existing Zod schemas. Get **2-75x faster** validation. No code changes required.
+Keep your existing Zod schemas. Get **2-45x faster** validation. No code changes required.
 
 - [What Gets Compiled](#what-gets-compiled)
 - [Schema Hoisting](#schema-hoisting)
@@ -38,48 +38,15 @@ import { z } from "zod";
 export const CreateUserSchema = z.object({
   name: z.string().min(1).max(100),
   email: z.email(),
-  age: z.number().int().min(0).max(150),
   role: z.enum(["admin", "editor", "viewer"]),
 });
-
-export const UpdateUserSchema = z.object({
-  name: z.string().min(1).max(100).optional(),
-  email: z.email().optional(),
-});
-
-export const ListUsersSchema = z.object({
-  page: z.number().int().min(1).optional().default(1),
-  limit: z.number().int().min(1).max(100).optional().default(20),
-});
-```
-
-**Use them as usual:**
-
-```typescript
-const user = CreateUserSchema.parse(data); // throws on failure
-const result = CreateUserSchema.safeParse(data); // { success, data/error }
 ```
 
-**Zero-allocation type guard — `.is()`:** compiled schemas also expose an `.is(input): input is T` boolean guard. For the common case (objects, primitives, arrays, enums with no `coerce`/`default`/`catch`/`transform`) this _is_ the compiled fast-check — one boolean expression, no `SafeParseResult`, no issues array — the cheapest possible "does this match?" check, on par with typia's `is<T>()` and a clean replacement for `schema.safeParse(x).success`:
-
-```typescript
-if (CreateUserSchema.is(data)) {
-  data.email; // narrowed to the schema's output type
-}
-const valid = items.filter((x) => CreateUserSchema.is(x));
-```
-
-Schemas without a total fast path fall back to `safeParse(input).success` (still correct). The guard is also available on `compile()`-wrapped schemas (Zod's runtime fallback before the build).
-
-At build time, the plugin:
-
-1. Finds every file with `import ... from "zod"` (skips type-only imports)
-2. Statically pre-filters: files whose exports provably can't be schemas (functions, components, constants) are skipped without ever being executed
-3. Executes the remaining candidates and detects exported Zod schemas
-4. Compiles each schema into an optimized validator
-5. Replaces the export with a tree-shakeable IIFE that preserves the full Zod API
+Use them as usual. Compiled methods are installed on the original schema object, so `.shape`, `._zod`,
+Standard Schema, `instanceof` and `z.toJSONSchema()` keep working and consumers need no changes.
 
-**What "preserves the full Zod API" means:** The optimized `parse`/`safeParse`/`parseAsync`/`safeParseAsync` methods (plus the `.is()` guard) are installed directly on the original schema object, which is exported as-is. Identity is preserved, so `._zod`, `.shape`, Standard Schema (`~standard`), `instanceof`, `.meta()` / `z.globalRegistry`, and `z.toJSONSchema()` all still work. Libraries that accept Zod schemas (tRPC, Hono, React Hook Form) work without changes.
+Compiled schemas also expose **`.is(input): input is T`** — the compiled check itself, allocating
+nothing. A drop-in replacement for `safeParse(x).success`.
 
 ### 2. compile() (Explicit)
 
@@ -123,9 +90,6 @@ npx zod-compiler generate src/ --schemas explicit --emit bag
 
 # Compact output: fast path only, cold errors delegated to Zod (~70% smaller)
 npx zod-compiler generate src/ --emit compact
-
-# Strip unknown keys from z.object() output (matches Zod's default .parse())
-npx zod-compiler generate src/ --strip-unknown-keys
 ```
 
 ## Build Plugin
@@ -147,18 +111,17 @@ npx zod-compiler generate src/ --strip-unknown-keys
 
 ### Options
 
-| Option             | Type                             | Default         | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
-| ------------------ | -------------------------------- | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `schemas`          | `"auto" \| "explicit"`           | `"auto"`        | How schemas are found. `"auto"`: every exported Zod schema compiles (also enables compiling hoisted in-function schemas). `"explicit"`: only `compile()`-wrapped schemas; only files importing zod-compiler execute at build time                                                                                                                                                                                                                                                  |
-| `include`          | `string[]`                       | —               | Only process files matching these path globs (picomatch, matched anywhere in the path; plain substrings work too)                                                                                                                                                                                                                                                                                                                                                                  |
-| `exclude`          | `string[]`                       | —               | Skip files matching these path globs (same matching rules as `include`)                                                                                                                                                                                                                                                                                                                                                                                                            |
-| `output`           | `"schema" \| "bag" \| "compact"` | `"schema"`      | What a compiled export evaluates to. `"schema"`: the original Zod schema with compiled methods installed (full API preserved). `"bag"`: a minimal methods-only object — smaller bundles, breaks Zod-schema consumers. `"compact"`: like `"schema"` but only the fast path is compiled — cold errors delegate to the retained Zod schema, dropping the slow walk (~70% smaller output, hot path unchanged). See [Compact Output](#compact-output-output-compact)                    |
-| `verbose`          | `boolean`                        | `false`         | Log per-schema compilation status during build                                                                                                                                                                                                                                                                                                                                                                                                                                     |
-| `hoist`            | `boolean`                        | `true`          | Hoist Zod schemas defined inside function bodies to module scope so they're constructed once instead of per call (babel-plugin-zod-hoist equivalent). Only expressions built purely from imports and literals are hoisted                                                                                                                                                                                                                                                          |
-| `apply`            | `"build" \| "serve" \| "all"`    | builds + Vitest | **Vite only**: when the plugin runs. By default, production builds and test runs are compiled (so tests exercise what ships); plain dev servers use the Zod fallback. `"all"` also compiles the dev server; `"build"` also skips tests                                                                                                                                                                                                                                             |
-| `codegenMode`      | `"lean" \| "inline"`             | auto            | Override the codegen mode. `"lean"` (default for all supported bundlers): shared runtime helpers are imported from `virtual:zod-compiler/runtime`, which the bundler resolves via its module hooks. `"inline"`: helpers are emitted directly into each transformed file — use this for transpile-only esbuild builds (no `--bundle`) or similar setups where the bundler's hooks never fire for already-transformed output and the `virtual:` specifier would survive into `dist/` |
-| `stripUnknownKeys` | `boolean`                        | `false`         | Strip unknown keys from `z.object()` output, matching Zod's default `.parse()`. Off by default (a valid object is returned by reference, keeping extras). When on, genuine `z.object()` schemas rebuild a fresh object with only the declared keys; `z.looseObject()` still keeps extras and `z.strictObject()` still rejects them. Use it to sanitize untrusted input against mass-assignment. See [Behavioral Differences](#behavioral-differences-from-zod)                     |
-| `cache`            | `boolean \| string`              | `true`          | Persistent transform cache (`node_modules/.cache/zod-compiler`, or a custom directory). Skips discovery + codegen across processes when nothing changed; entries self-validate against dependency content hashes                                                                                                                                                                                                                                                                   |
+| Option        | Type                             | Default         | Description                                                                                                 |
+| ------------- | -------------------------------- | --------------- | ----------------------------------------------------------------------------------------------------------- |
+| `schemas`     | `"auto" \| "explicit"`           | `"auto"`        | `"auto"` compiles every exported schema (and hoisted in-function ones); `"explicit"` only `compile()` calls |
+| `include`     | `string[]`                       | —               | Only process files matching these path globs                                                                |
+| `exclude`     | `string[]`                       | —               | Skip files matching these path globs                                                                        |
+| `output`      | `"schema" \| "bag" \| "compact"` | `"schema"`      | What a compiled export evaluates to — see [Compact Output](#compact-output-output-compact)                  |
+| `verbose`     | `boolean`                        | `false`         | Log per-schema compilation status                                                                           |
+| `hoist`       | `boolean`                        | `true`          | Move schemas built inside functions to module scope — see [Schema Hoisting](#schema-hoisting)               |
+| `apply`       | `"build" \| "serve" \| "all"`    | builds + Vitest | **Vite only**: when the plugin runs                                                                         |
+| `codegenMode` | `"lean" \| "inline"`             | auto            | `"inline"` emits helpers per file; needed for transpile-only esbuild — see [SWC](#swc)                      |
+| `cache`       | `boolean \| string`              | `true`          | Persistent transform cache in `node_modules/.cache/zod-compiler`                                            |
 
 ```typescript
 zodCompiler({
@@ -185,349 +148,101 @@ export default defineConfig({
 
 ### Bun
 
-zod-compiler is a **build-time** tool, so on Bun it compiles wherever your code
-passes through a build step; everywhere else schemas still run as plain Zod
-(correct, just not accelerated). The Bun plugin requires **Bun ≥ 1.2.22**.
-
-**Bundled code** (a frontend, or a server you `bun build --target=bun` first) —
-register the plugin and every exported (and hoisted) schema compiles:
+zod-compiler is a build-time tool, so on Bun it applies wherever your code passes through a build step.
+Requires **Bun ≥ 1.2.22**.
 
 ```typescript
 import zodCompiler from "zod-compiler/bun";
 
-await Bun.build({
-  entrypoints: ["./src/index.tsx"],
-  outdir: "./dist",
-  plugins: [zodCompiler()],
-});
+await Bun.build({ entrypoints: ["./src/index.tsx"], outdir: "./dist", plugins: [zodCompiler()] });
 ```
 
-**Code run straight from source** (`bun run src/server.ts`) — a `Bun.build` plugin
-doesn't run here, so use the [CLI](#3-cli-no-bundler) to compile ahead of time and
-import the output:
-
-```bash
-bunx zod-compiler generate src/ -o src/compiled/   # add --watch during development
-```
+For code run straight from source (`bun run src/server.ts`) no build plugin fires — use the
+[CLI](#3-cli-no-bundler) to compile ahead of time.
 
 ### Schema Hoisting
 
-Schemas defined inside functions are rebuilt on every call — a hidden cost in
-React components, request handlers, and helpers. With `hoist` (on by default),
-the plugin moves them to module scope:
+Schemas built inside functions are rebuilt on every call. With `hoist` (on by default) they move to
+module scope:
 
 ```typescript
-// before
+// before                                  // after
 function getSchema() {
-  return z.object({ name: z.string() }); // rebuilt per call
+  const _zh_94b7 = z.object({ name: z.string() });
+  return z.object({ name: z.string() });
+  function getSchema() {}
+  return _zh_94b7;
 }
-
-// after (build output)
-const _zh_94b7f5c1 = z.object({ name: z.string() });
-function getSchema() {
-  return _zh_94b7f5c1; // built once per module
-}
-```
-
-Hoisting is conservative: only expressions built purely from **imported
-bindings and literals** move. Anything referencing local variables,
-module-level bindings, `this`, or eagerly-evaluated globals (`new Date()`,
-`Math.random()`) stays where it is — though safe globals inside callbacks
-(`refine((v) => Number.isFinite(v))`) are fine, since callbacks run per parse
-regardless. Inline `.parse(...)` calls are peeled so evaluation stays at the
-call site (`z.string().parse(x)` → `_zh_….parse(x)`), names that are ever
-shadowed (`function f(z) {...}`) disqualify hoists referencing them, and
-identical schemas dedupe to a single binding.
-
-Combinator chains on imported schemas also qualify: bases matching
-`schemaNamePattern` (default `/ZodSchema$/`) or chains containing an inline
-`z.*` reference (`Base.extend({ a: z.string() })`). Configure via
-`hoist: { schemaNamePattern: /Shape$/ }` (string and `null` accepted).
-
-#### Hoisted schemas compile too (auto mode)
-
-The most common shape this rescues is a schema that never leaves a function —
-a [slonik](https://github.com/gajus/slonik) query, a tRPC input, a handler-local
-validator. It is not exported, so export scanning alone would never see it:
-
-```typescript
-import { pool, sql } from "./db.js";
-import { z } from "zod";
-
-const getUser = (id: number) => {
-  return pool.one(
-    sql.type(
-      z.object({
-        id: z.number(),
-        name: z.string(),
-      }),
-    )`SELECT id, name FROM users WHERE id = ${id}`,
-  );
-};
 ```
 
-In auto mode (the default), the build output is (verbatim, lightly trimmed):
+Only expressions built from imported bindings and literals move; anything touching locals, `this` or
+`new Date()` stays put. Combinator chains on imported schemas qualify via `schemaNamePattern`
+(default `/ZodSchema$/`).
 
-```typescript
-import { __zcFin, __zcFinD, __zcIT, __zcMkv } from "virtual:zod-compiler/runtime";
-const _zh_6c9cb1a3 = /* @__PURE__ */ (() => {
-  function __fc_0(input) {
-    return (
-      typeof input === "object" &&
-      input !== null &&
-      !Array.isArray(input) &&
-      Number.isFinite(input["id"]) &&
-      typeof input["name"] === "string"
-    );
-  }
-  function __sw_2(input) {
-    var _e = [];
-    /* error-collecting walk — runs only when .error is read */ return _e;
-  }
-  function safeParse__zh_6c9cb1a3(input) {
-    if (__fc_0(input)) {
-      return { success: true, data: input };
-    }
-    return __zcFinD(__sw_2, input);
-  }
-  return __zcMkv(
-    safeParse__zh_6c9cb1a3,
-    z.object({
-      id: z.number(),
-      name: z.string(),
-    }),
-    __fc_0,
-  );
-})();
-import { pool, sql } from "./db.js";
-import { z } from "zod";
-
-const getUser = (id: number) => {
-  return pool.one(sql.type(_zh_6c9cb1a3)`SELECT id, name FROM users WHERE id = ${id}`);
-};
-```
-
-Reading it bottom-up:
-
-- **The real Zod schema is still constructed** (once, at module load) and is the
-  object `_zh_6c9cb1a3` resolves to — `__zcMkv` installs the compiled
-  `parse`/`safeParse`/`parseAsync`/`safeParseAsync` as own properties on it and
-  returns it. `sql.type()` receives a genuine Zod schema (identity, `.shape`,
-  `._zod`, Standard Schema all intact) whose `safeParse` happens to be compiled.
-- **`__fc_0` is the Fast Path**: when slonik validates each row, a valid row
-  costs one boolean chain — no per-node traversal, no allocations beyond the
-  result object.
-- **`__sw_2` + `__zcFinD` are the failure path**: an invalid row returns
-  `{success: false}` immediately; the full error walk runs lazily only if
-  `.error` is actually read.
-- The `sql.type(...)` call itself stays at the call site (it closes over `id`
-  via the tagged template) — only its schema argument was hoisted and compiled.
-
-Measured on this exact pattern: schema construction + validation drops from
-~16,700ns to ~14ns per call — construction amortizes to module load, and
-per-row validation rides the Fast Path. With `schemas: "explicit"` the same file
-still gets the plain hoist (construction once instead of per call); the
-compiled IIFE requires auto mode (the default) because the schema is anonymous.
+In auto mode hoisted schemas also **compile** — which rescues the schema that never leaves a function
+(a slonik query, a tRPC input), invisible to export scanning. Measured on that pattern: ~16,700 ns →
+~14 ns per call.
 
 ### Bundle Size & Cross-File Dedup
 
-Generated validators share a small runtime helper layer (`__zcMkv` validator
-wrapper, issue factories like `__zcTS`/`__zcIT`, and well-known regexes for
-`email`, `uuid`, `cuid`, `ipv4`, etc.).
-
-On every supported bundler the plugin imports these helpers from a single
-plugin-provided runtime module — `virtual:zod-compiler/runtime` on Vite,
-Rollup, Rolldown, esbuild, Farm, and Bun, or the bare-specifier alias
-`__zod-compiler-runtime__` on webpack and rspack (which reject the `virtual:`
-URI scheme) — so the bundler emits a single bundle-wide copy regardless of how
-many files reference them.
+Validators share a runtime helper layer imported from one module, so each helper appears once per
+bundle. Schemas in a file sharing a structurally identical sub-shape emit its error walk once —
+**~50% raw / ~34% gzipped** on a realistic set.
 
-**Transpile-only esbuild builds** (no `--bundle`, e.g. `astro-scripts build`) never invoke the bundler's `onResolve`/`onLoad` hooks for already-transformed files, so the `virtual:` specifier survives verbatim into `dist/` and Node.js rejects it at runtime with `ERR_UNSUPPORTED_ESM_URL_SCHEME`. Set `codegenMode: "inline"` to emit helpers directly into each file instead:
+**Transpile-only esbuild builds** (no `--bundle`) never fire the bundler's resolve hooks, so the
+`virtual:` specifier would survive into `dist/` and fail at runtime. Set `codegenMode: "inline"` to emit
+helpers per file instead:
 
 ```typescript
-import zodCompiler from "zod-compiler/esbuild";
 export default [zodCompiler({ schemas: "explicit", codegenMode: "inline" })];
 ```
 
-The result: a 5-file project with 10 schemas all using `z.email()` and
-`z.uuid()` produces a bundle where each shared regex appears exactly **once**.
-Set `output: "bag"` to additionally drop the original Zod schema reference
-when you don't need `instanceof` / `.shape` access on the compiled output.
+Set `output: "bag"` to also drop the retained Zod schema when you don't need `.shape` / `instanceof`.
 
 ### SWC
 
-`zod-compiler/swc` is a **programmatic `@swc/core` bridge**, not a native
-`.swcrc` WASM plugin. Native SWC plugins run inside SWC's Rust/WASM plugin
-runtime; zod-compiler needs Node.js at build time to execute schema modules
-for discovery, so the SWC integration wraps `@swc/core.transform()` instead.
-
-Install `@swc/core` in the consuming project:
-
-```bash
-pnpm add -D @swc/core
-```
-
-Use the default factory when you want shared SWC/zod-compiler defaults:
-
-```typescript
-import zodCompiler from "zod-compiler/swc";
-
-const compiler = zodCompiler({
-  swc: {
-    jsc: {
-      parser: { syntax: "typescript", tsx: true },
-    },
-    sourceMaps: true,
-  },
-  zodCompiler: {
-    schemas: "auto",
-  },
-});
-
-const result = await compiler.transform(sourceCode, {
-  filename: "src/schemas.ts",
-});
-```
-
-Or use the one-shot helper:
+`zod-compiler/swc` is a programmatic `@swc/core` bridge, not a `.swcrc` WASM plugin — discovery needs
+Node.js, so it wraps `transform()`. Install `@swc/core`, then:
 
 ```typescript
 import { transform } from "zod-compiler/swc";
 
 const result = await transform(sourceCode, {
   filename: "src/schemas.ts",
-  swc: {
-    jsc: {
-      parser: { syntax: "typescript" },
-    },
-  },
+  swc: { jsc: { parser: { syntax: "typescript" } } },
 });
 ```
 
-The bridge defaults `codegenMode` to `"inline"` because SWC does not provide
-Rollup-style virtual module hooks for `virtual:zod-compiler/runtime`. If your
-pipeline runs another bundler after SWC and that bundler resolves the runtime
-specifier, you can opt into smaller lean output:
-
-```typescript
-await transform(sourceCode, {
-  filename: "src/schemas.ts",
-  zodCompiler: { codegenMode: "lean" },
-});
-```
-
-The bridge honors `include`/`exclude` globs (rejected files pass through to
-SWC without the zod-compiler step) and re-runs schema discovery when a
-file's content changes between calls, so watch-mode hosts pick up schema
-edits. It keeps no persistent disk cache — long-running hosts that want one
-should key cached transform results on file content.
-
-**Structural dedup within a file.** Beyond the shared runtime layer, schemas in
-the same file that contain a structurally identical sub-tree — a reused
-`Address`, a `Money` pair, an exported schema also embedded in another — emit
-that shape's error-collecting walk **once** as a shared function and call it
-from every occurrence. Only the cold error path is shared (it's 60–80% of the
-generated bytes); the zero-allocation fast path stays fully inlined, so valid
-input runs exactly as fast as before. On a realistic schema set where
-`User`/`Company`/`Order`/`Invoice` reuse `Address`/`Money`/`Contact`, generated
-output drops **~50% raw / ~34% gzipped** with no change to validation behavior.
+Defaults `codegenMode` to `"inline"` (SWC has no virtual-module hook); pass
+`zodCompiler: { codegenMode: "lean" }` if a later bundler resolves the runtime specifier. Honours
+`include`/`exclude` and keeps no disk cache.
 
 ### Compact Output (`output: "compact"`)
 
-Structural dedup only helps when shapes _repeat_. For a large app of mostly
-**distinct** schemas it can't fire, and the per-schema error-collecting walk —
-64–77% of the generated bytes — is emitted in full for every schema. But that
-walk exists only to reproduce Zod's issues on failure, and in `"schema"` mode
-**the original Zod schema is already in your bundle**. `output: "compact"`
-exploits this: it compiles the fast path as usual and, on a fast-check failure,
-delegates the cold error path to the retained schema's own `safeParse` instead
-of emitting a compiled slow walk.
-
-```typescript
-import zodCompiler from "zod-compiler/vite";
-
-export default defineConfig({
-  plugins: [zodCompiler({ output: "compact" })],
-});
-```
+The error-collecting walk is 64–77% of the generated bytes, and it only reproduces Zod's issues on
+failure — which the retained Zod schema already does. `output: "compact"` (CLI: `--emit compact`)
+compiles the fast path and delegates the cold error path to it.
 
-On a 50-schema set of distinct shapes (where dedup can't help), generated
-output drops **~73% raw / ~71% gzipped**:
-
-| Mode      |     Raw |   Gzip |
-| --------- | ------: | -----: |
-| `schema`  | 169,599 | 16,645 |
-| `compact` |  45,735 |  4,789 |
-
-The gzip win is far larger than collapsing duplicated code (which gzip already
-compresses well) because the slow walk is **removed**, not re-encoded.
-
-**What it costs — and doesn't:**
-
-- **Hot path unchanged.** `parse`/`safeParse` of valid input and the `.is()`
-  guard run the exact same compiled fast check as `"schema"` mode. Identity is
-  preserved (`.shape`, `.meta()`, `z.toJSONSchema()`, `instanceof`, tRPC/Hono
-  all keep working).
-- **Errors are Zod's own.** A failed `safeParse` reports byte-identical issues
-  to Zod — there is no second validation engine to drift, so correctness is
-  guaranteed by construction.
-- **Cold error reporting runs Zod.** Reading `.error` (or `.parse()` throwing)
-  on _invalid_ input runs Zod's full parse — slower than the compiled slow walk,
-  but it's the cold path. The delegation is **lazy**: `safeParse(x).success` and
-  `.is(x)` never invoke Zod (the fast check alone decides), so the common
-  validation-failure checks stay fast.
-- **Mutation schemas keep the compiled path.** Schemas that transform their
-  input (`default` / `catch` / `coerce` / `transform`) are compiled exactly as
-  in `"schema"` mode — only pure validators delegate.
-
-Use it when bundle size dominates (large schema counts, edge/serverless cold
-starts, memory at scale) and you can afford a slower _error_ path. It requires
-the Zod schema, so it's mutually exclusive with `output: "bag"` (which drops it).
-The CLI exposes it as `--emit compact`.
+On 50 distinct schemas, output drops **~73% raw / ~71% gzipped**. The hot path is unchanged, errors are
+Zod's own, and `safeParse(x).success` / `.is(x)` never invoke Zod — only reading `.error` does. Mutation
+schemas keep the compiled path. Mutually exclusive with `output: "bag"`.
 
 ### Auto Mode: Side Effects Warning
 
-In auto mode (the default), the plugin executes files to inspect their exports. A static pre-filter skips files whose exports provably can't be schemas without executing them — but if a file has schema-shaped exports AND side effects (starts a server, connects to a database), those side effects run at build time.
-
-**Fix:** Use `include` to limit which files are scanned:
-
-```typescript
-zodCompiler({
-  include: ["src/schemas", "src/validators"],
-});
-```
-
-#### Environment validation that calls `process.exit`
-
-A common pattern is an `env.ts` that validates `process.env` and calls
-`process.exit(1)` when required secrets are missing — schema files often import
-it transitively. In a CI build those secrets are intentionally absent, so
-executing the file at build time would otherwise terminate the bundler.
-
-zod-compiler guards against this. While it executes a module for discovery it:
+Auto mode executes files to inspect their exports, so a file with schema-shaped exports **and** side
+effects runs them at build time. Limit the scan with `include`.
 
-1. Sets `process.env.ZOD_COMPILER` so cooperating modules can skip validation.
-2. Intercepts `process.exit` — an unguarded exit becomes a normal load failure,
-   so the build **does not crash**. The affected files fall back to runtime Zod
-   and a one-time warning names the optimization that was skipped.
-
-To keep those schemas compiled, guard the exit on the marker:
+For the common `env.ts` that validates `process.env` and exits, zod-compiler sets
+`process.env.ZOD_COMPILER` during discovery and intercepts `process.exit`, so the build never crashes —
+those files just fall back to runtime Zod. To keep them compiled, guard on it:
 
 ```typescript
-// env.ts
 if (!process.env.ZOD_COMPILER) {
-  const result = envSchema.safeParse(process.env);
-  if (!result.success) {
-    console.error("Missing required environment variables:", result.error.format());
-    process.exit(1);
-  }
+  // ...validate and exit
 }
 ```
 
-If you use `@t3-oss/env-*`, pass `skipValidation: !!process.env.ZOD_COMPILER`.
-
-(Only synchronous exits during module evaluation are intercepted — an exit
-deferred to a `setTimeout` or later event still exits.)
+With `@t3-oss/env-*`, pass `skipValidation: !!process.env.ZOD_COMPILER`.
 
 ### schemas: "auto" vs "explicit"
 
@@ -541,111 +256,38 @@ deferred to a `setTimeout` or later event still exits.)
 
 ### Large projects and CI
 
-Discovery executes each schema file — and transitively its first-party import
-graph — inside the bundler's single-threaded process. In a repository where
-schema files pull in thousands of modules, the **first cold run** is the
-expensive part: subsequent runs hit the persistent cache and skip discovery
-entirely. On saturated CI hosts a cold discovery of a huge graph can stall the
-bundler's event loop long enough to trip test timeouts (the plugin warns when
-a single file's discovery exceeds 5s). Three levers, in order of impact:
-
-**1. Persist the cache across CI runs.** The cache directory is small
-(dependency snapshots are content-addressed and shared between entries) and
-entries self-validate against dependency content hashes — restoring a stale
-cache can only cause recompiles, never stale output:
+Discovery executes each schema file inside the bundler's process, so the **first cold run** is the
+expensive one — later runs hit the persistent cache.
 
 ```yaml
-# GitHub Actions
 - uses: actions/cache@v4
   with:
     path: node_modules/.cache/zod-compiler
     key: zod-compiler-${{ runner.os }}-${{ hashFiles('pnpm-lock.yaml') }}
-    restore-keys: zod-compiler-${{ runner.os }}-
-```
-
-**2. Scope what gets discovered.** `include` limits discovery to your schema
-directories. If test startup latency matters more than test-time validator
-performance, run hoist-only in Vitest and compile only real builds:
-
-```typescript
-// vitest.config.ts — hoisting still applies; validation uses plain Zod
-zodCompiler({ schemas: "explicit" });
-
-// vite.config.ts (build)
-zodCompiler({ include: ["src/schemas"] });
 ```
 
-**3. Measure before tuning.** `ZOD_COMPILER_TIMING=1` prints per-phase wall
-time (hoist / static-filter / discover / compile) on exit, so you can see
-whether discovery or codegen dominates and which files pay it.
-
-Everything else is automatic: the plugin declares
-[hook filters](https://vite.dev/guide/rolldown.html#hook-filter-feature) on
-its `transform`, `load` and `resolveId` hooks, so bundlers that support them
-(Vite, Rolldown, Rollup ≥ 4.40) never call the plugin for a module that cannot
-contain a schema — a file that never mentions `zod` costs nothing at all, not
-even a hook call. Bundlers without native support get the same filtering in
-JavaScript. The one exception is a custom `hoist.schemaNamePattern`: it
-promotes arbitrary imported identifiers to schema roots, so the content filter
-is dropped for that configuration (path filtering still applies).
+Cache entries self-validate against dependency hashes, so a stale cache can only cause recompiles.
+Scope discovery with `include`; set `ZOD_COMPILER_TIMING=1` to see per-phase wall time. Files that never
+mention `zod` cost nothing.
 
 ## Framework Examples
 
-### tRPC
-
-```typescript
-// src/schemas.ts
-import { z } from "zod";
-
-export const CreateUserSchema = z.object({
-  name: z.string().min(1).max(100),
-  email: z.email(),
-  age: z.number().int().min(0).max(150),
-});
-
-// src/router.ts
-import { CreateUserSchema } from "./schemas";
-
-export const appRouter = t.router({
-  createUser: t.procedure.input(CreateUserSchema).mutation(({ input }) => createUser(input)),
-});
-```
-
-In auto mode (the default), `CreateUserSchema` is compiled at build time. The tRPC router uses the optimized version automatically. No `.input(compile(CreateUserSchema))` needed.
-
-### Hono
+Nothing framework-specific is needed. In auto mode your exported schemas are compiled in place, so
+anything that accepts a Zod schema keeps working and picks up the compiled version:
 
 ```typescript
-import { Hono } from "hono";
-import { zValidator } from "@hono/zod-validator";
-import { UserSchema } from "./schemas";
-
-const app = new Hono();
+// tRPC — no .input(compile(...)) needed
+t.procedure.input(CreateUserSchema).mutation(({ input }) => createUser(input));
 
-app.post("/users", zValidator("json", UserSchema), (c) => {
-  const user = c.req.valid("json");
-  return c.json(user);
-});
-```
+// Hono
+app.post("/users", zValidator("json", UserSchema), (c) => c.json(c.req.valid("json")));
 
-### React Hook Form
-
-```typescript
-import { useForm } from "react-hook-form";
-import { zodResolver } from "@hookform/resolvers/zod";
-import { UserSchema } from "./schemas";
-
-function UserForm() {
-  const form = useForm({
-    resolver: zodResolver(UserSchema),
-  });
-  // ...
-}
+// React Hook Form
+useForm({ resolver: zodResolver(SignupSchema) });
 ```
 
-### Any Standard Schema Consumer
-
-Compiled schemas are the original Zod schema objects with optimized parse methods installed, so they still implement [Standard Schema](https://standardschema.dev). Any library that accepts Standard Schema validators works automatically.
+The same applies to any [Standard Schema](https://standardschema.dev) consumer — `~standard` is
+preserved and routes through the compiled validator.
 
 ## Schema Diagnostics
 
@@ -698,115 +340,47 @@ npx zod-compiler check src/schemas.ts --json --fail-under 80
 
 ## What Gets Compiled
 
-### Fully Compiled (2-75x faster)
+### Fully Compiled (2-45x faster)
 
-`string`, `number`, `bigint`, `boolean`, `null`, `undefined`, `any`, `unknown`, `literal`, `enum`, `stringbool`, `date`, `file`, `object`, `strictObject` / `.strict()`, `looseObject`, `array`, `tuple`, `record`, `set`, `map`, `union`, `discriminatedUnion`, `intersection`, `pipe` (non-transform), `optional`, `nullable`, `readonly`, `default`, `catch`, `coerce`, `templateLiteral`, `symbol`, `void`, `nan`, `never`, `lazy` (recursive — self-, mutual, and nested), `transform` / `refine` (zero-capture — see below)
+Every Zod type except the fallbacks below — all primitives, `object` / `strictObject` / `looseObject`,
+`array`, `tuple`, `record`, `set`, `map`, `union`, `discriminatedUnion`, `intersection`, `pipe`,
+the `optional` / `nullable` / `readonly` / `default` / `catch` / `coerce` wrappers, `templateLiteral`,
+recursive `lazy` (self, mutual and nested), and `transform` / `refine` / `superRefine`.
 
-All standard Zod checks are supported: `min`, `max`, `length`, `email`, `url`, `uuid`, `regex`, `int`, `positive`, `negative`, `multipleOf`, `int32`, `uint32`, `float32`, `float64`, `includes`, `startsWith`, `endsWith`, and more.
+All standard checks are supported: `min`, `max`, `length`, `email`, `uuid`, `regex`, `int`, `positive`,
+`multipleOf`, `includes`, `startsWith`, and the rest.
 
 ### Falls Back to Zod (Still Works, Not Faster)
 
-These reach JavaScript that generated code cannot reproduce — an opaque callback, or control flow that depends on one:
-
-| Type                                     | Why                                                          | Alternative                                    |
-| ---------------------------------------- | ------------------------------------------------------------ | ---------------------------------------------- |
-| `transform` that is async or takes `ctx` | A promise result, or zod's issue-collection protocol         | Use a plain single-argument callback           |
-| `superRefine` followed by another check  | An aborting issue truncates zod's remaining checks           | Put the `superRefine` last in the chain        |
-| `custom` / raw `.check(fn)`              | Arbitrary validation logic against zod's raw payload         | Use `superRefine`, which compiles              |
-| `preprocess`                             | Input preprocessing function                                 | Use `z.coerce` when possible                   |
-| `lazy` (unresolvable inner)              | Getter throws / inner type can't be resolved at compile time | Ensure the lazy getter returns a static schema |
-
-**Zero-capture effects compile:** a `transform`/`refine` callback that takes a
-single argument and references only its own parameters, locals, and safe
-globals (`Math`, `Number`, `JSON`, …) is extracted via `fn.toString()` and
-inlined into the generated validator. `z.string().transform((s) => s.trim())`
-compiles; `z.string().transform((s) => s + suffix)` falls back (it captures
-`suffix`).
-
-**Every `refine` and `transform` compiles, captures or not.** A callback that
-cannot be inlined is instead **called by reference** — the generated validator
-invokes your own function object, reached from the schema — so the schema keeps
-its compiled path either way. This matters most on the root, where one captured
-callback used to send the whole object through Zod:
-
-- `z.object({ … }).refine((d) => d.password === d.confirm)` — the cross-field
-  check. Measured on a six-field object: **246.7 ns → 8.5 ns (29x)**, against
-  Zod's own 250.5 ns.
-- `z.object({ … }).transform((d) => ({ ...d, id: prefix + d.id }))` —
-  **163.7 ns → 12.7 ns**. That case was previously _slower than not compiling
-  at all_ (Zod itself: 136.7 ns), because the delegate wrapper sat on top of
-  Zod's parse.
-
-Where the callback itself dominates, compiled output reaches its cost and no
-more: a captured `refine` doing `allowedDomains.some(…)` measures 23.9 ns
-against 24.1 ns for calling that predicate alone — zero remaining validation
-overhead.
-
-**`superRefine` compiles too.** It has no verdict to read — the callback takes
-Zod's payload and pushes issues onto it — so it is called through a reference to
-Zod's own wrapper with a synthesized payload, which leaves issue construction
-Zod's job and keeps error shapes identical by construction. That turns the most
-common form of cross-field validation from a total fallback into the 2.3M →
-13.3M row below; measured in isolation, where the harness floor stops
-compressing the ratio, the same object runs 357.8 ns → 39.9 ns (9.0x) and an
-array of numbers 240.7 ns → 5.3 ns (46x), with rejecting inputs 31-92x. Two
-shapes still delegate: a `superRefine` with another check after it
-(an issue marked `fatal` aborts Zod's remaining chain, which generated code —
-running every check — cannot reproduce), and a raw `.check(fn)`, where the
-callback holds the payload unmediated rather than through Zod's wrapper. An
-`async` callback is invisible at compile time, since the reference points at the
-wrapper; the promise it returns raises Zod's own `$ZodAsyncError`, exactly as a
-synchronous Zod parse does. `ctx.value`, `ctx.aborted`, and direct
-`ctx.issues.push` are all honored.
-
-**`.catchall(schema)` compiles.** Unknown keys are validated against the value
-schema by the same bare `for-in` the `strict` pass uses — zod's own
-`handleCatchall` iteration, inherited enumerable keys included — with each issue
-reported at its key. A header bag (`z.object({...}).catchall(z.string())`)
-measures 117.2 ns → 9.0 ns (**13x**), a numeric metrics bag 105.1 ns → 11.5 ns
-(9.1x); both were 1.0x. Value-rewriting catchalls (`z.coerce.number()`,
-`.trim()`, a `.default()`) write through a clone, so the caller's input is never
-mutated. A catchall that itself delegates keeps the whole object delegated —
-one zod call beats one per unknown key.
-
-**Partial fallback:** If an object has 10 properties and 1 uses `transform`, the other 9 are still compiled. Only the `transform` property falls back to Zod.
-
-**Recursive schemas compile** — whether directly self-recursive (`z.lazy(() => Self)`), mutually recursive (`A` ↔ `B`), or **nested as a field of a larger root** (a recursive `Comment` inside `z.object({ thread, root: Comment })`). Each distinct recursive shape is hosted once as a dedicated validator and reached by reference, so the whole structure stays on the fast path instead of delegating to Zod — a recursive type nested in an API envelope runs **12–32x faster than Zod** (see the benchmark table). A `lazy` schema only falls back when its getter can't be resolved at compile time.
-
-**Tip:** Run `npx zod-compiler check` to see exactly which parts of your schemas are compiled and which fall back.
-
-### Behavioral Differences from Zod
-
-Compiled validators match Zod on accept/reject decisions, output data for the known shape, and error messages — including issue ordering for multi-failure inputs. A few observable behaviors differ **by design**, all stemming from the zero-allocation fast path: a successful parse returns the **input value itself** rather than rebuilding it.
+A schema delegates to Zod when it reaches JavaScript the generated code cannot reproduce:
 
-| Behavior                               | Zod                              | zod-compiler                                                                     |
-| -------------------------------------- | -------------------------------- | -------------------------------------------------------------------------------- |
-| Unknown keys on a default `z.object()` | Stripped from the output         | **Kept** by default — returned by reference; opt in with `stripUnknownKeys`      |
-| Record key iteration                   | All own keys (`Reflect.ownKeys`) | Own **enumerable string** keys only — symbol and non-enumerable keys are ignored |
-| Array / object output identity         | A fresh value                    | The input value, returned by reference                                           |
+| Construct                                   | Why                                                                        |
+| ------------------------------------------- | -------------------------------------------------------------------------- |
+| `.check(fn)`, `superRefine` + later checks  | The callback holds Zod's payload unmediated, or `fatal` aborts Zod's chain |
+| `ctx`-taking or `async` transforms          | Needs Zod's parse context / the async pipeline                             |
+| `z.custom()`, `z.instanceof()`              | No extractor yet                                                           |
+| `z.url()`, `z.jwt()`                        | Algorithmic formats (`new URL()`, signature parsing)                       |
+| Object intersections                        | Zod parses both sides and merges; the compiler cannot reproduce the merge  |
+| Dynamic error maps, unresolvable `z.lazy()` | Not knowable at build time                                                 |
 
-What this means in practice:
+Everything else compiles, including `transform`/`refine`/`superRefine` whether or not the callback
+captures — a zero-capture one is inlined, a capturing one called by reference. Delegation is
+per-sub-schema: one uncompilable field goes to Zod, not the whole object. Run `zod-compiler check` to
+see what compiled.
 
-- **Unknown keys are not stripped by default.** `z.object({ a: z.string() }).parse({ a: "x", b: 1 })` returns `{ a: "x" }` under Zod but `{ a: "x", b: 1 }` compiled. Three ways to get stripping behavior, in order of preference:
-  - Enable the **`stripUnknownKeys`** build option (or the `--strip-unknown-keys` CLI flag). Genuine `z.object()` schemas then rebuild a fresh object with only the declared keys — exactly matching Zod's default strip, including nested objects, array elements, `.pick()`/`.partial()`/`.extend()` results, and discriminated-union options. This is the right choice if you forward parsed request bodies to an ORM and need protection against mass-assignment / overposting. (Cost: stripped objects are rebuilt on every successful parse, so they no longer take the by-reference fast path.)
-  - Use **`z.strictObject()`** if you'd rather reject unknown keys outright (changes the API contract — extras become errors).
-  - Use **`z.looseObject()`** to make the default keep-extras behavior explicit at the schema level.
-
-  All three compile fully, and validation of the declared keys is identical in every case.
-
-  **Performance of `stripUnknownKeys`** (`pnpm benchmark strip-unknown-keys`): stripping rebuilds the object, so it gives up the by-reference fast path — but the rebuild is a single object literal per level, which costs little next to the validation itself. Representative throughput:
-
-  | Schema (input)                | Zod (strips) | compiler (keep, default) | compiler (strip) | strip vs keep | strip vs Zod |
-  | ----------------------------- | ------------ | ------------------------ | ---------------- | ------------- | ------------ |
-  | medium object, 7 keys (clean) | 2.7M         | 13.5M                    | 12.7M            | 0.94x         | **4.7x**     |
-  | wide object, 20 keys (clean)  | 4.0M         | 24.4M                    | 18.1M            | 0.74x         | **4.5x**     |
-  | nested API response (clean)   | 176K         | 9.3M                     | 5.4M             | 0.58x         | **31x**      |
+### Behavioral Differences from Zod
 
-  The tax scales with nesting depth (one fresh object per level), not really with key count, and is independent of whether unknown keys are actually present. It is small enough that you should turn stripping on wherever you want sanitization — forwarding parsed bodies to an ORM, for instance — rather than trading it away for throughput.
+Compiled validators match Zod on verdicts, output data and error messages, including issue ordering.
+Two things differ by design, both from the zero-allocation fast path:
 
-- **Records skip symbol / non-enumerable keys.** `z.record(z.string(), …)` validates (and rejects) a symbol-keyed or non-enumerable-keyed entry under Zod; the compiled record never visits it. Plain string-keyed records — the common case — are unaffected.
+| Behavior                  | Zod                                | zod-compiler                                            |
+| ------------------------- | ---------------------------------- | ------------------------------------------------------- |
+| Record key iteration      | All own keys (`Reflect.ownKeys`)   | Own enumerable **string** keys only                     |
+| Container output identity | A fresh array / set / map / object | The input container, by reference (array holes survive) |
 
-Matching Zod on these would mean allocating a fresh object (or a `Reflect.ownKeys` array) on every successful parse — the exact cost the fast path exists to avoid.
+A container whose contents need no rewriting is validated in place and handed back, where Zod always
+rebuilds it. `z.object()` is the exception — it strips unknown keys exactly as Zod does, so its output
+is always a fresh object.
 
 ## Benchmark
 
@@ -814,46 +388,46 @@ Matching Zod on these would mean allocating a fresh object (or a `Reflect.ownKey
 
 | Scenario                                        | Zod v3 | Zod v4 | **zod-compiler** | Typia | AJV   | vs Zod v4 |
 | ----------------------------------------------- | ------ | ------ | ---------------- | ----- | ----- | --------- |
-| simple string                                   | 13.3M  | 14.5M  | **17.3M**        | 17.7M | 17.9M | 1.2x      |
-| string (min/max)                                | 12.4M  | 8.0M   | **17.0M**        | 17.9M | 15.7M | 2.1x      |
-| number (int+positive)                           | 12.6M  | 8.3M   | **17.4M**        | 18.0M | 18.1M | 2.1x      |
-| enum                                            | 12.3M  | 12.6M  | **17.6M**        | 17.8M | 18.3M | 1.4x      |
-| bigint (min/max)                                | 12.2M  | 7.8M   | **17.0M**        | —     | —     | 2.2x      |
-| tuple [string, int, bool]                       | 5.9M   | 6.5M   | **16.5M**        | 16.5M | 16.4M | 2.6x      |
-| record\<string, number\>                        | 3.2M   | 2.8M   | **15.2M**        | 11.9M | 15.7M | 5.5x      |
-| set\<string\> (5 items)                         | 3.7M   | 2.3M   | **15.0M**        | —     | —     | 6.5x      |
-| set\<string\> (20 items)                        | 1.3M   | 715K   | **11.8M**        | —     | —     | **16x**   |
-| map\<string, number\> (5 entries)               | 2.0M   | 1.4M   | **13.2M**        | —     | —     | 9.6x      |
-| map\<string, number\> (20 entries)              | 665K   | 360K   | **8.4M**         | —     | —     | **23x**   |
-| pipe (non-transform)                            | 8.7M   | 5.7M   | **16.7M**        | —     | —     | 2.9x      |
-| discriminatedUnion (3 variants)                 | 3.5M   | 4.2M   | **16.0M**        | 15.9M | 7.9M  | 3.9x      |
-| discriminatedUnion (8 variants, rotating)       | 2.7M   | 3.5M   | **10.1M**        | —     | —     | 2.9x      |
-| plain union of 8 tagged objects (auto-discrim.) | 374K   | 678K   | **10.0M**        | —     | —     | **15x**   |
-| strict object (DB row)                          | 1.8M   | 3.2M   | **8.1M**         | —     | —     | 2.5x      |
-| medium object (valid)                           | 1.9M   | 2.4M   | **9.9M**         | 11.5M | 7.6M  | 4.1x      |
-| medium object (invalid)                         | 553K   | 80K    | **15.1M**        | 3.0M  | 7.8M  | **188x**  |
-| large object (10 items)                         | 122K   | 166K   | **7.9M**         | 6.1M  | 1.2M  | **48x**   |
-| large object (100 items)                        | 14K    | 18K    | **1.4M**         | 1.3M  | 127K  | **77x**   |
-| recursive tree (7 nodes)                        | 589K   | 2.1M   | **12.8M**        | 12.0M | 4.9M  | 6.0x      |
-| recursive tree (121 nodes)                      | 32K    | 143K   | **2.5M**         | 2.0M  | 392K  | **18x**   |
-| nested recursion (7 nodes)                      | 394K   | 1.0M   | **12.1M**        | 11.1M | 3.0M  | **12x**   |
-| nested recursion (121 nodes)                    | 25K    | 66K    | **2.1M**         | 1.7M  | 219K  | **32x**   |
-| deeply nested object (243 leaves)               | 11K    | 20K    | **1.2M**         | 1.1M  | 129K  | **59x**   |
-| event log (combined)                            | 389K   | 645K   | **6.4M**         | —     | —     | 9.9x      |
-| object with transform (zero-capture)            | 1.2M   | 2.0M   | **6.3M**         | —     | —     | 3.1x      |
-| array 10 × transform (zero-capture)             | 126K   | 208K   | **3.3M**         | —     | —     | **16x**   |
-| array 50 × transform (zero-capture)             | 26K    | 45K    | **839K**         | —     | —     | **19x**   |
-| object with captured transform                  | 1.3M   | 6.4M   | **15.0M**        | —     | —     | 2.4x      |
-| object with captured refine (cross-field)       | 1.6M   | 2.5M   | **16.1M**        | —     | —     | 6.4x      |
-| object with superRefine (cross-field)           | 1.6M   | 2.3M   | **13.3M**        | —     | —     | 5.7x      |
-
-_ops/s, higher is better. "—" = not supported by the library. Measured with `vitest bench` on Apple M4 Max (zod 4.3.6, zod v3 3.23.8, typia 12, ajv 8), best of two full runs; rows reproduce within ~5% between runs. The harness itself costs ~55 ns per iteration — the fastest rows sit at that floor — so it compresses the top of the range: gaps between the three AOT columns on the primitive rows are below the noise, not real._
-
-Performance scales with schema complexity. Nested objects and arrays see the biggest gains because zod-compiler eliminates per-node traversal overhead. Deeply nested schemas (the 243-leaf dashboard row) stay fast because oversized fast-check functions are split into smaller boolean helpers, each kept within V8's optimizing-compiler budget. `discriminatedUnion` dispatches instead of trying options in sequence the way Zod does, and each case validates only its variant's distinctive fields — the object type-guard and the discriminator are checked once before dispatch, never re-checked inside the matched case (a redundancy the engine only elides on unions small enough to inline, so large unions get a measured ~1.5x on the fast check). Dispatch is genuinely O(1) for string discriminators: a `switch` over string labels is only _written_ as a jump, V8 lowers it to sequential `===` comparisons (~0.5 ns per preceding case, so 52 ns of pure dispatch at 80 variants), so the discriminator goes through a `{value: ordinal}` table into a dense integer switch — measured 1.9x at 8 variants and 2.8x at 60, for ~1% more generated bytes. Unions of two variants, or with non-string discriminators, keep the plain switch. A **plain `z.union`** of objects that all pin a shared key to disjoint literals is auto-detected and lowered to the same switch dispatch — so an untagged union written without `discriminatedUnion` still validates in O(1) (15x faster than Zod here), as long as it has enough options to outweigh the switch's setup cost; below that it keeps the fully-inlined `||`-chain, whose options and per-option checks are ordered cheapest-first so a non-matching option is dropped without running its regexes. The invalid-input row is large because failed `safeParse` defers error materialization until `.error` is read. `transform`/`refine` callbacks compile whether or not they capture (3-19x): a zero-capture one is inlined from its source, a capturing one is called by reference rather than costing the schema its compiled path — the cross-field refine row measures 2.5M → 16.1M, and captured transforms went from matching Zod (1.0x) to 2.4x. `superRefine` compiles as well, called through a reference to Zod's own payload wrapper (2.3M → 13.3M here, from a total fallback); only a `superRefine` with another check after it, raw `.check(fn)`, and `ctx`-taking or async transforms still delegate.
-
-`parse()` (throwing API) rides a zero-allocation fast path: medium object 2.4M → 10.2M ops/s (4.3x), large object (100 items) 18K → 1.4M ops/s (78x).
-
-The `.is()` guard answers both halves of "does this match?" cheaply — 10.3M ops/s on matching input and **16.8M on non-matching**, against Zod's 2.4M / 159K via `safeParse().success` (medium object). Rejection is the _faster_ half by construction: the fast check's conjuncts are ordered so a mismatch is decided on a type guard rather than on the schema's most expensive check — 106x Zod, which pays full error construction to say no.
+| simple string                                   | 12.9M  | 14.5M  | **16.9M**        | 17.2M | 17.5M | 1.2x      |
+| string (min/max)                                | 12.1M  | 7.6M   | **16.3M**        | 17.6M | 14.9M | 2.1x      |
+| number (int+positive)                           | 11.5M  | 7.7M   | **16.5M**        | 16.8M | 17.7M | 2.1x      |
+| enum                                            | 11.8M  | 12.2M  | **16.8M**        | 17.1M | 17.2M | 1.4x      |
+| bigint (min/max)                                | 11.4M  | 7.6M   | **15.9M**        | —     | —     | 2.1x      |
+| tuple [string, int, bool]                       | 5.5M   | 6.3M   | **15.9M**        | 16.8M | 15.3M | 2.5x      |
+| record\<string, number\>                        | 3.2M   | 2.7M   | **15.5M**        | 12.3M | 15.3M | 5.7x      |
+| set\<string\> (5 items)                         | 3.6M   | 2.3M   | **15.0M**        | —     | —     | 6.6x      |
+| set\<string\> (20 items)                        | 1.3M   | 695K   | **11.9M**        | —     | —     | **17x**   |
+| map\<string, number\> (5 entries)               | 2.0M   | 1.3M   | **12.4M**        | —     | —     | 9.5x      |
+| map\<string, number\> (20 entries)              | 613K   | 352K   | **8.3M**         | —     | —     | **24x**   |
+| pipe (non-transform)                            | 8.7M   | 5.6M   | **16.8M**        | —     | —     | 3.0x      |
+| discriminatedUnion (3 variants)                 | 3.4M   | 4.0M   | **16.7M**        | 16.0M | 7.9M  | 4.1x      |
+| discriminatedUnion (8 variants, rotating)       | 2.7M   | 3.5M   | **9.8M**         | —     | —     | 2.8x      |
+| plain union of 8 tagged objects (auto-discrim.) | 358K   | 646K   | **9.5M**         | —     | —     | **15x**   |
+| strict object (DB row)                          | 1.8M   | 3.1M   | **11.0M**        | —     | —     | 3.6x      |
+| medium object (valid)                           | 1.5M   | 2.3M   | **9.4M**         | 10.9M | 7.4M  | 4.0x      |
+| medium object (extra keys stripped)             | 1.8M   | 2.2M   | **9.4M**         | —     | —     | 4.3x      |
+| medium object (invalid)                         | 536K   | 79K    | **14.2M**        | 3.0M  | 7.7M  | **180x**  |
+| large object (10 items)                         | 118K   | 162K   | **5.2M**         | 5.8M  | 1.2M  | **32x**   |
+| large object (100 items)                        | 13K    | 18K    | **811K**         | 1.4M  | 125K  | **45x**   |
+| recursive tree (7 nodes)                        | 589K   | 2.1M   | **8.1M**         | 11.9M | 4.9M  | 3.8x      |
+| recursive tree (121 nodes)                      | 32K    | 128K   | **803K**         | 1.9M  | 386K  | 6.3x      |
+| nested recursion (7 nodes)                      | 395K   | 1.0M   | **7.1M**         | 8.8M  | 2.5M  | 7.0x      |
+| nested recursion (121 nodes)                    | 23K    | 61K    | **804K**         | 1.4M  | 184K  | **13x**   |
+| deeply nested object (243 leaves)               | 11K    | 20K    | **832K**         | 1.0M  | 124K  | **42x**   |
+| event log (combined)                            | 377K   | 623K   | **7.3M**         | —     | —     | **12x**   |
+| object with transform (zero-capture)            | 1.1M   | 2.0M   | **6.0M**         | —     | —     | 3.0x      |
+| array 10 × transform (zero-capture)             | 120K   | 204K   | **3.7M**         | —     | —     | **18x**   |
+| array 50 × transform (zero-capture)             | 25K    | 41K    | **963K**         | —     | —     | **24x**   |
+| object with captured transform                  | 1.3M   | 6.1M   | **15.2M**        | —     | —     | 2.5x      |
+| object with captured refine (cross-field)       | 1.6M   | 2.5M   | **13.7M**        | —     | —     | 5.5x      |
+| object with superRefine (cross-field)           | 1.5M   | 2.3M   | **11.7M**        | —     | —     | 5.0x      |
+
+_ops/s, higher is better. `vitest bench` on an Apple M4 Max (zod 4.3.6, zod v3 3.23.8, typia 12, ajv 8),
+best of two runs. The harness costs ~55 ns per iteration, so the fastest rows sit at that floor and gaps
+between the AOT columns there are noise, not real._
+
+Nested objects, arrays and recursive types gain the most. Rejection is fast because a failed
+`safeParse` defers building the error until `.error` is read.
 
 ```bash
 pnpm benchmark   # run locally
@@ -861,24 +435,16 @@ pnpm benchmark   # run locally
 
 ### Performance Architecture
 
-For eligible schemas, zod-compiler generates a **two-phase validator**:
-
-1. **Fast Path** — A single `&&` expression chain that validates the entire input with zero allocations. Valid input returns immediately.
-2. **Slow Path** — Error-collecting validation that only runs when the Fast Path fails.
-
-Additional optimizations: pre-compiled regex, per-type check ordering (a string's `.min()` before its format regex), discriminated-union cases that skip the now-redundant object-guard and discriminator re-check after `switch` dispatch, and auto-discrimination of plain `z.union`s of tagged objects into the same switch dispatch.
-
-**Cheapest-first check ordering.** A fast check is one `&&` chain, so accepting input runs every conjunct whatever the order — but a _rejection_ stops at the first false one. Object properties, tuple positions, intersection sides and union options are therefore emitted in estimated-cost order, cheap type guards ahead of regex formats and nested containers. Valid input is unaffected; deciding that input does _not_ match gets much cheaper, which is what `.is()` guards, `z.union` probing and every failed `safeParse` actually do. Measured per validator (no harness overhead) on a 3-option union of objects declaring `{email, kind, note}`: an input matching the last option 102 ns → 39 ns (2.6x), one matching none 102 ns → 6 ns (16x); a 6-property object guard rejecting a wrong-typed field 38 ns → 5 ns (8x).
-
-**Object construction.** Where a fresh object must be produced — `stripUnknownKeys` — it is emitted as one object literal rather than assembled key by key. V8 stamps a literal out of a cached boilerplate map in a single allocation; adding keys one at a time walks a transition chain and re-checks the map on every store, which measured 8.1x slower on a 20-key shape. Keys that can be absent (optionals) are appended after the literal, in shape order, under zod's own presence rule.
-
-**Local bindings for called helpers.** Lean mode imports its shared helpers from the plugin's runtime module, and a bundler leaves those as module-scope `var`s. V8 folds a _local_ binding into a constant callee and inlines straight through `helper.call(...)`; a mutable module-scope one it will not, so the record fast path's per-key `__zcHop.call(o, k)` became a generic call. Aliasing such helpers into the IIFE once fixes it: measured on a plugin-transformed, esbuild-bundled artifact, a 5-key record went 34.6 ns → 9.2 ns and a 20-key record 157.3 ns → 23.1 ns. Only helpers invoked through `.call` need this — a direct call to an imported function, and an imported RegExp receiver, are both unaffected.
-
-**One declaration per value.** Constant tables — an enum's `Set`, a strict shape's key list, a file's mime list — are keyed by their initializer, so a value list reached from both the fast check and the slow walk, or shared by sibling properties, is emitted once rather than per use. Worth 18-21% of the generated bytes on enum-heavy schemas, and 10% raw / 5% gzip across a realistic schema set.
-
-**Membership tests.** A strict object's unknown-key pass consults an object literal (`TABLE[k] === 1`) rather than a `Set`, whose `has` costs a flat ~4 ns hash probe per key however small the set — 3.7x (8 keys) to 4.5x (32 keys) faster over the same for-in, taking an 8-key strict object from 53 ns to 32 ns end to end. Enum values keep the existing split: an inlined `===` chain up to 5 values, one `Set` lookup above that.
+An eligible schema compiles to a **fast path** — one `&&` chain validating the whole input with zero
+allocations, reused by `.is()` and `parse()` — plus a **slow path** that collects errors, run only on
+failure and deferred until `.error` is read. A `z.object()` strips, so it instead compiles to a single
+pass that validates and rebuilds together, bailing on the first failure. That pass also covers the
+idioms that reshape a value — array size checks, `.refine()`, `.default()`, `.trim()`, `.transform()` —
+so one of them in a schema no longer costs it the whole single-pass parse.
 
-Run `npx zod-compiler check --json` to see which schemas qualify for Fast Path.
+Regexes are pre-compiled with bounded repeats unrolled, checks run cheapest-first, discriminated unions
+dispatch through a jump table (plain tagged unions are auto-discriminated into it), and oversized check
+functions are split to stay within V8's optimizer budget.
 
 ## Development