ata-validator

ata diff <old> <new>: what a change to a schema does to documents. The documents ata verify makes, from both schemas, plus the project's samples, are checked by a Validator built from each schema; the ones the old schema accepts and the new one rejects, and the reverse, are reported grouped by the rule that decides them, with one example each. Exit code 1 when the new schema rejects what the old one accepted, so a pull request that tightens a schema fails the check until someone looks. lib/schema-diff.js, tests/test_schema_diff.js.

ata-validator/compiled-standard: bareStandard(mod, schema), the compiled-module wrapper for a validator that is only ever handed to a Standard Schema consumer (a router's validator middleware, a form library, an RPC layer) and never called by its own code. Such a consumer reads ~standard alone, and an issue is a message and a path, so the wrapper is built on a module written with plainErrors: true and carries no error pipeline: 733 bytes gzipped, standing alone as an ES module. The issues, the input after defaults and the Standard JSON Schema document are the runtime's on every suite case the compiler takes (tests/test_compiled_standard.js). @ata-project/unplugin uses it where it sees that handover, through Hono's sValidator, hono-openapi, TanStack Form, oRPC, tRPC's .input() and Elysia's hooks: a Hono route bundled for Cloudflare Workers goes from 21.0 to 12.2 KB gzipped against 7.7 KB for Hono alone, an Elysia route from 120.1 to 110.1 against 106.8, a tRPC procedure from 18.0 to 7.8 against 4.6.

Under Bun's ahead-of-time compiler a runtime Validator took generated code again, which the compiler interprets: 487 ns a document against 78 on the interpreted engine. ata told the two apart by Bun.isAOT, which the compiler's pull request has since removed in favour of an "aot" export condition. The package now leads its exports with that condition, naming index.aot.js and index.aot.mjs, which mark the process before the package loads (lib/aot-mark.js), and lists them as side effects so a bundler keeps them. Measured on the pull request's build of 2026-10-27; tests/test_aot_entry.js holds the condition, the entries and the mark.

ata-validator/compiled-bare-rich: bareRich(mod, schema), the bare wrapper for a validator that reads ata's own errors, the same errors as fromCompiledObject without Standard Schema and the extension hook. @ata-project/unplugin uses it for a validator only ever called; the two-validator form app went from 13.5 to 10.7 KB gzipped. Held to a default Validator in tests/test_compiled_bare.js.

compiledModuleFor(schema, { verdictOnly: true }) writes the module for a reader that only ever calls isValid(), without its error collector (its validate() hands out the abort-early stub): 954 to 539 bytes gzipped on a one-field object. @ata-project/unplugin writes verdict-wrapper modules this way, and keeps the full module for verify. The richErrors: false form app went from 3.8 to 3.5 KB gzipped.

ata-validator/compiled-bare: bareVerdict(mod) and barePlain(mod), the smallest compiled-module wrappers (315 bytes gzipped for both), for a validator the bundler plugin sees used only through direct calls of validate() or isValidObject() and never handed to other code, so nothing reads ~standard or registers a check on it. Defaults are filled with the module's own pass; barePlain hands out the plain errors of a plainErrors module. @ata-project/unplugin uses them where that holds: the form app with richErrors: false went from 6.1 to 3.8 KB gzipped. tests/test_compiled_bare.js holds them to the runtime on 22,315 answers over the suite.

ata-validator/compiled-plain: fromCompiledPlain(mod, schema, { richErrors: false }), the compiled-module wrapper for a Validator built with richErrors: false, around a module written with compiledModuleFor(schema, { plainErrors: true }), whose one-pass program writes errors in that plain shape and order. It hands them out as they are and carries no rejection classes, enrichment or suggestions: 2.6 KB gzipped. @ata-project/unplugin compiles such a validator away with it, where it kept it on the runtime before. A form app with one validator that reads errors and one that asks for a boolean went from 16.7 KB gzipped on 1.61.0 to 6.1 with richErrors: false. tests/test_compiled_plain.js holds it to the runtime on 17,852 answers over the suite in five dialects. Standard Schema reaches the enrichment only for a native engine's message-less error, now through lib/native-message.js, which the browser build maps to a stub, since a browser has no native engine.

ata-validator/compiled-object: fromCompiledObject(mod, schema), the compiled-module wrapper without validateJSON() and isValidJSON(), for code that reads errors but never validates JSON text. The position map those entry points use to frame an error in the text stays out of the bundle: 10.9 KB gzipped against 12.8 for the full wrapper. @ata-project/unplugin picks it where the replaced validator is never asked to validate JSON text. tests/test_compiled_parity.js holds it to the runtime over the suite.

ata verify also tries, for every bound a schema states (minimum, maximum, the exclusive ones, multipleOf, minLength, maxLength), a value on either side of it, on a document the runtime accepts. Its random documents rarely land on a bound, so a module that read one off by one (a minimum of 13 written as < 12) answered all 200 of them as the runtime did and passed; it is now caught, with the runtime saying invalid and the module valid. tests/test_verify.js holds the case.

A schema with a default anywhere (ata fills defaults without being asked, so it has a preprocess pass) now builds its rich errors where they fail, as other schemas do: the path was closed to schemas with a preprocess pass, though it reads the document validate() has already processed. One required error on a four-field user with a defaulted newsletter went from 313 to 248 ns with its error list read; only the one-pass swap, which replaces validate() itself, stays off for such schemas. Found through the fastest-validator comparison in ata-core/validator-benchmarks (issue #74).

The Node entry warms the engine once the event loop is free: where a validator was built and is still untouched by then (not compiled, no method read off it), one check of a small schema runs, accepted and rejected, so that V8 compiles the generator's functions and the error builders before the first request instead of on it. On a four-field schema with the generator already loaded, a server's first verdict went from 3.1 to 3.4 ms to 0.5 to 0.6, the first error list from 6.7 ms to 0.8, at 1.5 to 2 ms of CPU once. A script that builds and checks in the same tick never runs it, the timer is unref'd, and ATA_NO_WARM=1 turns it off. The browser build has done the same since 1.57.0 (lib/tiering.js); the cold-start benchmarks, which check in the same tick as they build, are unchanged by it. tests/test_node_warm.js holds the conditions.

ata-validator/build exports bunTarget (the schema as a TypeScript type and the .bun.ts module ata build --target bun writes; with tags: true the split into a type with Bun's Schema tags and a residual schema, made for the typed validator the compiler's pull request carried until 2026-10-25) and verify (verifyOne, verifySource, generate), for a build plugin that replaces new Validator(schema) inside a Bun.build({ compile: { aot: true } }) and holds what it wrote against the runtime.

ata verify <glob> holds each schema's compiled module against a runtime Validator built from the schema now: documents made from the schema (--generate, 200 by default, half with one rule broken), the project's sample documents (--samples, JSON or JSON Lines files or a directory), verdicts and error lists compared, a module whose schema hash no longer matches the schema reported stale, a non-zero exit on any disagreement, stale or missing module, --json for machines. The check behind the fixes of 1.59.0 and 1.60.0, as a command a project runs in CI.

A validator the build compiled away (fromCompiled around a module written ahead of time, what @ata-project/unplugin puts in place of new Validator(schema)) carries Standard Schema V1 as the runtime Validator does: the same ~standard object, built by lib/standard-schema.js for both, with the same issues, value and published schema. A compiled validator can now be handed to a form library, a router or an RPC layer that reads ~standard. tests/test_compiled_standard.js compares the two.

toStandaloneModule(schema, { coerceTypes }) and toStandaloneModule(validator) for a validator built with coerceTypes or removeAdditional wrote a module that checked the data as it was, so it rejected { id: "5" } where the validator accepts it. The module now runs the validator's pass over the data before the check, as bundleStandalone does since 1.59.0, and refuses where that pass cannot be written into a module. fastify-ata/standalone builds its files through this call.

bundleStandalone(schemas, { order: true }) hands each validator's errors out in the runtime's order, as toStandaloneModule does with the same option. rjsf's precompiled validator writes its module with bundleStandalone, and its error list showed an additionalProperties error before the properties errors where the runtime validator shows it after. tests/test_aot_order_defaults.js holds 553 bundled groups of the 2020-12 and draft-07 suites to the runtime's errors, in order.

Each validator of a bundle whose schema has a default carries applyDefaults(data), the runtime's defaults pass, as a property, as standalone modules export it. rjsf's precompiled validator can call it to match its runtime validator. tests/test_bundle_preprocess.js compares 8400 generated documents with the runtime: the data afterwards, the verdict and the errors in order.

bundleStandalone left coerceTypes and removeAdditional out without a word, so a bundle built with coerceTypes: true rejected { age: "5" }, which the runtime accepts. Each bundled validator now runs the runtime's pass over the data for those options before it checks, and with useDefaults: true fills defaults the same way. Where the generated pass cannot carry what the runtime would do (coercing the items of an array at the root, for one), bundleStandalone throws instead of writing a module that answers differently. Without these options a bundle checks the data as it is, as before.

bundleStandalone and bundleCompact modules threw ReferenceError: _cpLen is not defined on a string whose minLength or maxLength needed counting code points: a one-character value under minLength: 1, an emoji under a maxLength. The length checks call a code-point counter that toStandaloneModule embeds and the two bundles did not. This goes back to 1.10.0 at least, and reached forms built on rjsf's precompiled validator, which uses bundleStandalone: typing one character into a required name field threw. The bundles now embed the counter when their code calls it; tests/test_bundle_cplen.js runs both bundles in both formats.