chore: bump ata-validator from 0.5.1 to 1.9.0

[dependabot]

Bumps ata-validator from 0.5.1 to 1.9.0.

Release notes

Sourced from ata-validator's releases.

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

• 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.

v1.8.0

Added

... (truncated)

Changelog

Sourced from ata-validator's changelog.

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

Added

• $vocabulary is honoured when a schema names a custom meta-schema in $schema. A dialect is a set of vocabularies and a vocabulary is a set of keywords, so a keyword whose vocabulary the meta-schema does not declare is not part of that dialect at all: it is an unknown keyword, and an unknown keyword is ignored. A schema written against a meta-schema which declares only the core and applicator vocabularies now has its minimum, type and the rest of the validation keywords ignored, while properties and the other applicators still apply. The keywords belonging to each vocabulary are read from the vendored meta-schemas rather than from a list kept by hand, so they come from the specification. Removing the keyword before compilation means every engine agrees without any of them knowing what a vocabulary is.

  This closes the last case ata missed. Draft 2020-12 goes from 1298 to 1299 of 1299, with draft 7 at 927 of 927 and the v1 dialect at 1133 of 1133, the same with code generation blocked. tests/run_suite.js has no known failures left.

  Two things it does not do. It does not refuse a schema whose meta-schema requires, with true, a vocabulary ata does not recognise; the specification says an implementation must refuse there, and turning what has always been silently accepted into a hard failure is a separate decision, so such a schema is evaluated as before with every keyword applied. And a separate document reached through $ref keeps its own keywords rather than inheriting the referring dialect, so a document which should follow one needs to say so with its own $schema.

Fixed

• bundleStandalone and bundleCompact built the error-reporting function from the schema the caller passed rather than the one the validator compiled. Anything which prepares a schema therefore reached the boolean path and not the error path: with assertFormat: false the bundle reported a format error the caller had turned off, and only once some other keyword failed first, since the error function runs only after the boolean one says no. toStandalone already read the compiled schema; these two now do as well.

... (truncated)

Commits

• f8b19ba chore: bump to 1.9.0
• e40b66f docs: document the new error fields, the renderers and the frame limitation
• 9bf4137 perf: keep the diagnostic payload off the validate() path
• 049cb7a fix: state the frame reconstruction note once per report
• c82253d feat: render diagnostics with locations, distinct headlines and clamped carets
• 4cef076 feat: add the diagnostic layer between errors and renderers
• 7bb06ff feat: carry a diagnostic source payload on the errors array
• 020fd80 feat: add detail, anchor, rank and related to rich errors
• 3d525f0 feat: correlate typo pairs with tie checks on both sides
• 5b48e18 feat: record key token spans in the data position map
• 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 #5.