ata-validator

The standalone module's error collector (the default form, with schema-source frames) reads each property once into a local, names a closed object's declared keys outright instead of a Set lookup per key when there are at most eight, and reuses the node's plain-object flag in that walk instead of reading the prototype again. A rejected ten-item order with its error list built went from 378 to 244 ns on Node (the one-pass form, 102, is unchanged and still opt-in for its size); the module's size does not move. Found by profiling line by line: one closedness walk held 31% of the samples.

ata build --target bun writes the one-pass error function by default and no schema-source frames, as an executable compiled ahead of time pays no bundle size: a rejected ten-item order with the error list built went from 724 to 189 ns under Bun's compiler (on Node, 378 to 105 against 99 for the runtime). The default for every other build stays the older collector with frames, since the one-pass form is 20% larger gzipped over 60 SchemaStore schemas (53 of them larger by more than 5%, the worst 1.6x); --one-pass and --no-source choose it by hand. The plugin's ahead-of-time path does the same.

Generated code walks and counts a closed object's keys in the form of the engine it is written for: for...in on V8, where it is the cheaper form, an indexed loop over Object.keys on JavaScriptCore, where for...in is a slow path. The runtime writes for the engine it runs on; ata build --target bun and the plugin's Bun entry write for JavaScriptCore. One form is written, so neither engine pays a branch per object (an earlier form with a load-time flag cost V8 5 to 7% on small schemas). A third form, jsc-aot, is what --target bun and the plugin's ahead-of-time path write: a closed object whose declared keys are all required is checked by reading Object.keys once and comparing it with the declared list in order, the order JSON.parse gives, with a membership walk when the order differs. Under Bun's compiler that put the plain module level with Bun's own validate<T> on a ten-item order (105 to 107 ns against 96 to 105, from 108 to 112); on Bun's JIT the same form loses 5 to 15 ns, which is why it is its own target. The prototype read picks __proto__ on V8 and Object.getPrototypeOf on JavaScriptCore at generation. Measured on a ten-item order: Bun 1.4.4's JIT 65 to 53 ns a document, Bun's ahead-of-time compiler (pull request build) 227 to 108, Node 25 unchanged.

Requiring the package no longer loads the code generator. It loads when a validator first compiles, or once the event loop is free, so a server reaches its first request without waiting for it. Importing the package went from 4.55 to 1.64 ms (Node 25, the median of 21 interleaved runs), and a server building 20 validators at startup from 4.71 to 1.83 ms. Validators still compile at their first call, and a script that validates as soon as it starts takes as long as before. benchmark/bench_fastify_boot.mjs now counts loading the library on both sides, as "from a cold process" says; the README's Fastify figure moves from 18.3 against 2.67 ms (loading left out) to 30.3 against 9.7 ms.

default values are filled in every schema applied to a value, as the default validator's useDefaults fills them: behind a $ref into the same document (recursive ones included), in each allOf member, in array elements under items and prefixItems, under additionalProperties and patternProperties for the keys they cover, and under dependentSchemas for the keys present. The pass stopped at properties, so a required property whose default sat behind a reference or in an array element was rejected where the default validator accepts it. anyOf, oneOf and not fill nothing, as there. if/then/else fill nothing here either, since which branch applies is only known once the value has been checked; the default validator fills some of those cases. On SchemaStore's sample documents for the 372 schemas with defaults it compiles (1,287 documents), the filled data differs from the default validator's on 161 documents, down from 488, and the verdict on 23, down from 42; every remaining difference is in a schema with oneOf, anyOf, if or not. All three passes fill the same: the generated one, the closure one (the interpreted engine, and where the generated pass declines a schema), and a module's applyDefaults, which now embeds the closure pass where the generated one declines: 405 of 878 SchemaStore modules export applyDefaults, up from 289. tests/test_defaults_reach.js covers each place, against values taken from the default validator, and 300 generated schemas on all three passes.

This can reject a document that was accepted before, when a schema's own default breaks one of its rules. Of SchemaStore's 1,537 positive samples, 17 are now rejected; the default validator with useDefaults rejects 16 of them. The 17th fills layout: true where a sibling then says not: { required: ["layout"] }: the default validator checks allOf before it fills properties, ata fills first. useDefaults: false leaves the input as it is.

Inside a value the pass made from a default, a schema already applied to an enclosing value is not applied again. A schema whose object default refers back to an enclosing one would otherwise fill without end; Renovate's schema did, and the default validator throws a RangeError on it. An empty Renovate configuration fills to 22,774 bytes, as before.

A validator whose schema has defaults, or that coerces, builds its errors when they are read, as other validators do. It built them on every rejection, read or not: on Kestra's schema that was 25 ms of the first validate() spent ordering errors nobody asked for. A rejection on a small schema with defaults went from 46 to 22 ns when the errors are not read.

A schema whose defaults would expand past the generated pass's size limit is handed to the closure pass before any code is written. SARIF's schema wrote 4,000 lines in 2.7 ms and threw them away. The generated source is unchanged on all 1,692 SchemaStore cases checked.

In the browser build, the plan compiler, which turns a schema the interpreted engine checks often into a tree of closures, is no longer in the page's first load. It arrives through a dynamic import, a chunk of its own in a bundler that splits, once the page is idle after its first validator (lib/interpreter.browser.js, which the package.json browser field puts in place of lib/interpreter.js). Until then the plain walk answers, as it already did for each schema's first thousand calls, with the same answers and the same depth of data before the stack runs out. The first load is 53,953 bytes gzipped, from 58,245 in 1.57.0. In Chrome with the CPU slowed 4x and a 1.6 Mbps link, a react-hook-form page with ataResolver was ready in 1,594 ms instead of 1,672 (1,668 for a second copy of 1.57.0); the first submit 300 ms after the form was built went from 2.50 to 2.25 ms, and a submit before the page was idle did not move (17.43 and 16.86 before, 16.92 after). With code generation blocked, a hot validator answers as before once the chunk is in (49.5 ns a rejection, both). tests/test_browser_plan_lazy.js covers the split and the answers before and after.