ata-validator

A browser bundle carries only the tools it imports. The ESM entries bundlers read (index.browser.mjs, index.edge.mjs) import TypeScript generation, the renderers, the output format, the retry message and the schema description one by one, where index.js loads them on first call through require, which a bundler follows but cannot drop. An application that imports only Validator, bundled for the browser with esbuild, went from 130.9 KB gzipped (1.49.0) to 123.5 KB. Node keeps loading them on first call.

The interpreted engine (ata-validator/lite, and the default entry wherever code generation is blocked) compiles its closure tree once a schema has been used 1000 times, and answers the calls before that with its plain walk. Building the tree for a whole schema cost as much as 3000 to 30000 plain walks on SchemaStore schemas, so a page or a short-lived worker paid for it on its first check and never got it back; the compiler's own source is now loaded only when it is needed. In a minified bundle with code generation blocked, the first check of a SchemaStore schema of 3.3 KB went from 2.94 to 2.20 ms, 10.8 KB from 5.15 to 4.24, 33 KB from 6.34 to 5.27, 97 KB from 10.83 to 6.39, and tsconfig's 469 KB from 13.86 to 11.99; importing is unchanged, and so is the cost of a check once the tree is built (432 against 447 ns, 342 against 336, 650 against 653). A server that validates thousands of documents pays at most the walk's extra cost over its first 1000 calls, which on tsconfig is 0.85 ms, once. Two things the plain walk did differently from the tree came out once it answered real calls, and both are fixed: it checked custom keywords only on leaf nodes, so a keyword beside properties was skipped (the tree answered every call before, and compiled every schema of the official suite, so this was not reachable in a release), and data nested about 700 levels deep overflowed its stack where the tree's did not; such data now goes to the tree. tests/test_interpreter_tiering.js holds the walk to the tree on the suite's 3365 cases.

The interpreted engine recognises leaf plans again. Its index records a base URI for every schema node, and the plan read that as a resource boundary on every node, so no plan was ever a leaf and every value check went through the full evaluation prologue. A plan now carries a base only where a resource starts; references already hand their target's base over. On the engine without its plan compiler (the shared error runtime), a 30-field flat object goes from 939 to 916 ns and a four-field request body from 118 to 113 ns, measured twice each with the same order of results.

A compact module sets nothing up at import: its schema is parsed and the runtime prepared on the first rejected document whose errors are read. Importing three compact modules takes 4.00 ms against 4.67 for the self-contained ones, eight take 5.50 against 7.65. The first error list a page reads costs more instead, once: 4.50 against 2.76 ms for three validators, 6.59 against 4.82 for eight, so import and first error read together are 8.50 against 7.43 ms for three and 12.09 against 12.47 for eight; after that a rejection costs the same (about 0.09 ms on these schemas). What is left of the difference is the runtime's own code being compiled on its first use, about 1.1 ms. In a browser the runtime does that when the page is idle (requestIdleCallback, once, on a small schema of its own), so the first real error list finds it compiled: with an idle moment between load and the first rejection, a one-property schema's first error read takes 0.61 ms against 0.74 for a self-contained module, and three SchemaStore schemas after it 2.86 against 2.67. In Node it does the same once the event loop is first free after start-up, on a timer that keeps no process alive, so a server has it done before its first request (0.60 against 0.75 ms, and 2.85 against 2.65 for the three schemas after it); a rejection in the same synchronous step as the import, before the loop turns, still pays it. Workers allow no timer at start-up, and there nothing runs ahead. On data nested deeper than its walk can go (thousands of levels), the runtime reports the module's ATA9000 stub instead of throwing; the verdict still comes from the module. Two things keep that first read down: the runtime sorts errors by walking only the paths they name, where the runtime Validator numbers every node of the schema on its first sort, and a build tells the runtime when a schema has no embedded resource or anchor, so it does not index the schema (1.29 to 0.20 ms on the first schema measured).

The interpreted engine builds error paths only while it collects errors. A verdict walk concatenated an instance path and a schema path for every child it visited and never read them: on the 22 KB assessment file above, 48.1 to 40.7 µs.

A compact module reports the errors the runtime Validator reports with richErrors: false (and, like the self-contained module, without errorMessage), in its order: the order of the keywords in the schema. A self-contained module reports them in the order its collector meets them, which differs (a parent's additionalProperties before the child properties' errors, for instance). Neither order was documented. Checked over the official suites in five dialects and 13741 SchemaStore documents: no verdict differs from the self-contained module, and every error list equals the runtime's. On that corpus the self-contained module differed from the runtime in 23 error lists (the errors inside a oneOf branch) and left allOf: [false] without its ATA4005 code; on 73 documents it could only report ATA9000, where the compact module reports the errors.