chore: bump ata-validator from 0.5.1 to 1.10.0

[dependabot]

Bumps ata-validator from 0.5.1 to 1.10.0.

Release notes

Sourced from ata-validator's releases.

1.10.0

Performance

• The code generator takes shapes it used to decline for no correctness reason: boolean subschemas in items, properties, patternProperties, dependentSchemas, propertyNames, allOf, anyOf, not, contains and if/then/else, recursive #/$defs/ references as named functions, and additionalProperties as a schema alongside composition or patternProperties. Each lands in all three generators and the closure path, held to the interpreter by tests/test_codegen_edge_shapes.js and the entry-point agreement test over the whole official suite. Every suite group that moved off the interpreter got faster, 31 of 31 on draft 2020-12 and 28 of 28 on draft 7, summed per-group time down 70 percent. The suite-wide figure, measured interleaved against the previous release in one process, did not move outside that measurement's noise; benchmark/verdict-bench.md has the numbers and says why.
• date and ipv4 format checks read the string once with no regular expression and no allocation: 45.7 to 14.2 ns and 54.5 to 27.1 ns on a valid value, interleaved medians. Fuzzed against the previous forms with 0 mismatches; tests/test_formats_single_pass.js keeps it that way.

Fixed

• A key matched only by the second of two patternProperties entries, alongside additionalProperties: false, was rejected: the generated key loop returned at the first pattern that missed. Found while rewriting that loop; covered by the edge-shape test.
• A declared property that also matched a patternProperties entry skipped the pattern's schema in the generated code when additionalProperties was a schema. The suite's own interaction case caught it the moment the shape was allowed to compile.

v1.9.0

Errors

• Rendered diagnostics now say where the problem is. Every renderPretty and renderCompact block carries the JSON path, and a source frame with a caret on the failing token when one can be built faithfully: from the text on the validateJSON path, or from the object when the renderer is handed { data }. Object-input frames are reconstructed by re-serializing the value and the output says so once, because the line numbers refer to that reconstruction. No frame is reconstructed under coerceTypes, removeAdditional or a schema with default values, since the object in hand is not what the caller sent; the output names the option instead.
• Headlines state the observation rather than the rule: expected integer, found string in place of must be integer. Two additionalProperties violations no longer render as identical blocks; the property name is in the headline. A composition failure with a const discriminator names it, no variant matches kind "circle", anchors inside the closest branch, and its branch notes read minimum: expected ≥0, found -1.
• A property typed nmae where name was required renders as one diagnostic with did you mean "name"? instead of two. The correlation requires that no other missing or extra key in the same object is equally close; on a tie nothing is merged. Both errors stay in the array and point at each other through the new related field, and the footer reads 8 schema violations in input, shown as 7 diagnostics so the count never drifts from errors.length.
• Diagnostics are ordered by document position, with cause before effect only as a tie-break within one container. Carets are clamped to the line they sit under; a root-level error used to draw one the width of the whole document.
• Under richErrors (the default) errors gain detail, related, anchor and rank. Existing fields, array order and array length are unchanged; richErrors: false still returns the v0.14 shape. useDefaults, on by default, is now documented.
• Measured on a ten-case corpus scored on four questions per diagnostic (says where, states what was found, distinguishable from its neighbours, offers a way forward): 3 of 60 before, 58 of 58 after, and tests/test_diagnostics_score.js holds the floor at 95%. Cost on the reject path when .errors is read, master against this change on the same machine: a one-error document 330 to 395 ns, a seven-error document with a typo pair 2.45 to 2.95 µs. validate().valid is unchanged at 5 ns. Fastify's own suite through fastify-ata stays at 178 of 184.

Requires no code changes. richErrors errors gain four fields; existing fields, array order and array length are unchanged.

v1.8.2

Fixed

A pattern of the form ^[class]+$, ^[class]{m,n}$ or ^[class]{n}$ with n above 16 could be violated without validate() saying so.

The boolean program compiles those patterns to an inline character loop wrapped in an arrow function. The rewrite that turns the boolean program into the error-reporting one replaced the return false and return true inside that arrow with return E(d) and return R. Both are objects, so the arrow returned a truthy value on mismatch, the enclosing !(cond && obj) went false, and the error program accepted what the boolean program had rejected.

What that looked like depended on the path:

• Without preprocessing, validate() still rejected, because the boolean verdict runs first, but the error was a generic schema validation failed with no keyword, no params.pattern and no path.
• With preprocessing, which means any schema carrying a default, or a validator built with coerceTypes or removeAdditional, the error program is installed as validate() directly and the result was valid: true.
• Validator.bundleStandalone and bundleCompact embed the same program and had the same silent accept.
• ata compile output is built from the boolean program and was not affected.

The rewrite has been wrong since 0.6.0. The official suite never exercises these pattern shapes, so nothing caught it. The rewrite now leaves the body of an arrow function alone, the same way it already left function bodies alone.

tests/test_hybrid_agreement.js compares the rewritten program with the boolean it came from on every affected shape, at the root, in a property, in array items, through bundleStandalone and through a compiled module, and checks the two preprocessing cases directly. tests/test_codegen_entrypoint_agreement.js now compares the rewritten program as a fifth participant across the whole official suite. tests/test_ajv_errors.js, which had been failing on exactly this for as long as the bug existed, is now part of npm test.

If you use coerceTypes, removeAdditional, schemas with default values, or bundleStandalone, and your schemas contain patterns of these shapes, update.

Changed

Ranking an error into schema declaration order no longer re-derives the rank on every error of every failing document. The rank is cached per path under its root and each node's keys are indexed once. That function drops from 8.5% to 1.4% of the error path, and the error path as a whole gets 3.5% faster, median of eleven interleaved runs.

v1.8.1

Changed

... (truncated)

Changelog

Sourced from ata-validator's changelog.

1.10.0 - 2026-08-30

Performance

• The code generator takes shapes it used to decline for no correctness reason: boolean subschemas in items, properties, patternProperties, dependentSchemas, propertyNames, allOf, anyOf, not, contains and if/then/else, recursive #/$defs/ references as named functions, and additionalProperties as a schema alongside composition or patternProperties. Each lands in all three generators and the closure path, held to the interpreter by tests/test_codegen_edge_shapes.js and the entry-point agreement test over the whole official suite. Every suite group that moved off the interpreter got faster, 31 of 31 on draft 2020-12 and 28 of 28 on draft 7, summed per-group time down 70 percent. The suite-wide figure, measured interleaved against the previous release in one process, did not move outside that measurement's noise; benchmark/verdict-bench.md has the numbers and says why.
• date and ipv4 format checks read the string once with no regular expression and no allocation: 45.7 to 14.2 ns and 54.5 to 27.1 ns on a valid value, interleaved medians. Fuzzed against the previous forms with 0 mismatches; tests/test_formats_single_pass.js keeps it that way.

Fixed

• A key matched only by the second of two patternProperties entries, alongside additionalProperties: false, was rejected: the generated key loop returned at the first pattern that missed. Found while rewriting that loop; covered by the edge-shape test.
• A declared property that also matched a patternProperties entry skipped the pattern's schema in the generated code when additionalProperties was a schema. The suite's own interaction case caught it the moment the shape was allowed to compile.

1.9.0 - 2026-08-28

Errors

• Rendered diagnostics now say where the problem is. Every renderPretty and renderCompact block carries the JSON path, and a source frame with a caret on the failing token when one can be built faithfully: from the text on the validateJSON path, or from the object when the renderer is handed { data }. Object-input frames are reconstructed by re-serializing the value and the output says so once, because the line numbers refer to that reconstruction. No frame is reconstructed under coerceTypes, removeAdditional or a schema with default values, since the object in hand is not what the caller sent; the output names the option instead.
• Headlines state the observation rather than the rule: expected integer, found string in place of must be integer. Two additionalProperties violations no longer render as identical blocks; the property name is in the headline. A composition failure with a const discriminator names it, no variant matches kind "circle", anchors inside the closest branch, and its branch notes read minimum: expected ≥0, found -1.
• A property typed nmae where name was required renders as one diagnostic with did you mean "name"? instead of two. The correlation requires that no other missing or extra key in the same object is equally close; on a tie nothing is merged. Both errors stay in the array and point at each other through the new related field, and the footer reads 8 schema violations in input, shown as 7 diagnostics so the count never drifts from errors.length.
• Diagnostics are ordered by document position, with cause before effect only as a tie-break within one container. Carets are clamped to the line they sit under; a root-level error used to draw one the width of the whole document.
• Under richErrors (the default) errors gain detail, related, anchor and rank. Existing fields, array order and array length are unchanged; richErrors: false still returns the v0.14 shape. useDefaults, on by default, is now documented.
• Measured on a ten-case corpus scored on four questions per diagnostic (says where, states what was found, distinguishable from its neighbours, offers a way forward): 3 of 60 before, 58 of 58 after, and tests/test_diagnostics_score.js holds the floor at 95%. Cost on the reject path when .errors is read, master against this change on the same machine: a one-error document 330 to 395 ns, a seven-error document with a typo pair 2.45 to 2.95 µs. validate().valid is unchanged at 5 ns. Fastify's own suite through fastify-ata stays at 178 of 184.

1.8.2 - 2026-08-28

Fixed

• A pattern of the form ^[class]+$, ^[class]{m,n}$ or ^[class]{n}$ with n above 16 could be violated without validate() saying so. The boolean program compiles those patterns to an inline character loop wrapped in an arrow function, and the rewrite that turns the boolean program into the error-reporting one replaced the return false and return true inside that arrow with return E(d) and return R. Both are objects, so the arrow started returning a truthy value on mismatch, the enclosing !(cond && obj) went false, and the error program accepted what the boolean program had rejected.

  What that looked like from outside depended on the path. Without preprocessing, validate() still rejected, because the boolean verdict runs first, but the error it produced was a generic schema validation failed with no keyword, no params.pattern and no path. With preprocessing, which means any schema carrying a default or a validator built with coerceTypes or removeAdditional, the error program is installed as validate() directly and the result was valid: true. Validator.bundleStandalone and bundleCompact embed the same program and had the same silent accept. ata compile output is built from the boolean program and was not affected. The rewrite has been wrong since 0.6.0; the official suite never exercised these pattern shapes, so nothing caught it.

  The rewrite now leaves the body of an arrow function alone, the same way it already left function bodies alone. tests/test_hybrid_agreement.js compares the rewritten program with the boolean it came from on every affected shape, at the root, in a property, in array items, through bundleStandalone and through a compiled module, and checks the two preprocessing cases directly. tests/test_codegen_entrypoint_agreement.js now compares the rewritten program as a fifth participant across the whole official suite. tests/test_ajv_errors.js, which had been failing on exactly this for as long as the bug existed, is now part of npm test.

Changed

• Ranking an error into schema declaration order no longer re-derives the rank on every error of every failing document. It was splitting the schema path with two regular expressions per segment and then scanning Object.keys(node) at each level, which was 8.5% of the error path in a profile, for an answer that depends only on the schema and the path. The rank is now cached per path under its root, each node's keys are indexed once, and escape handling is skipped for segments with no tilde. That function drops from 8.5% to 1.4% of the error path, and the error path as a whole gets 3.5% faster, median of eleven interleaved runs. docs/performance-notes.md records the larger gap this was measured against; it is not closed by this change.

1.8.1 - 2026-08-27

Changed

• Constructing a validator no longer clones and serializes every schema to find out whether it needed normalizing. It did that on the root and on each registered schema: serialize, deep clone, normalize the clone, serialize again, compare. For a schema with no nullable field and no draft-07 keyword the answer is always no, and the work was thrown away. Every question the normalizers ask is whether some key appears anywhere in the tree, so one walk answers all of them, and the clone now happens only for schemas that need it. No registry and ten fields goes from 18.5 to 4.6 µs; fifty registered schemas of fifty fields, which is a small server's worth, from 2570 to 260 µs.

  The walk descends through every object-valued key rather than the subschema keywords the normalizers recurse through, so it is a superset of what they visit: it can report work where there is none, costing one clone, and cannot miss work there is. Across the 2344 schemas in the official suite it reports work on 335 where normalization changes 334. tests/test_schema_scan.js asserts that direction over the whole suite, and asserts the check is load-bearing by breaking the scan deliberately and confirming the broken one is caught.

  The answer is remembered against the schema object, the way whole compiled validators already are, and so is the schema map built from a registry. Both were being redone once per validator, so a server building one validator per route over a shared registry paid for that registry once per route. Fifty routes over twenty shared schemas boots in 0.046 ms rather than 20.66 ms. Validators share the map, and anything that writes to one, which is addSchema() and the meta-schema registration during compilation, takes a private copy first.

  Nothing about what any schema validates to changes. The comparison that decided the old answer is still there behind the walk, so a schema the walk sends down the slow path gets exactly the result it got before.

1.8.0 - 2026-08-27

... (truncated)

Commits

• 9438550 chore: bump to 1.10.0
• 69cd82a merge: verdict path speed, codegen coverage for boolean and recursive schemas
• d59c395 docs: measured verdict-path figures after the three changes
• 725b802 perf: single-pass date and ipv4 format checks
• 4315fb5 docs: the cycle guard measures as no change; not pursued
• d6ad012 perf: compile additionalProperties schemas under composition and patternPrope...
• 4692fd7 perf: compile recursive $defs as named functions instead of declining
• 75ce6f7 perf: compile boolean members of allOf, anyOf, not, contains and if/then/else
• 40a79fd perf: compile boolean patternProperties, dependentSchemas and propertyNames
• e8f4a6b perf: compile boolean property schemas instead of declining them
• Additional commits viewable in compare view

Maintainer changes

This version was pushed to npm by GitHub Actions, a new releaser for ata-validator since your current version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

Superseded by #6.