chore: bump ata-validator from 0.5.1 to 1.11.0

[dependabot]

Bumps ata-validator from 0.5.1 to 1.11.0.

Release notes

Sourced from ata-validator's releases.

1.11.0

Fixed

• The verdict methods answer the same question as validate() again. With coerceTypes, removeAdditional or a schema default in play, validate() ran the preprocess pass and isValidObject(), isValidJSON() and validateJSON() did not, so the same validator answered true from one and false from another for the same document: validate({ age: '26' }) accepted where isValidObject({ age: '26' }) rejected. Every path now runs the same pass. Verdict methods on a validator configured this way rewrite the input in place, as validate() already did, and the cost of the correction is 0.5 ns on isValidObject and 2.7 ns on isValidJSON, measured interleaved; validators without those options are unchanged. tests/test_verdict_preprocess.js holds all four methods to the same answers.

• The native engine's error codes no longer reach callers untranslated. A type failure answered by the addon came back as code: 3 with no keyword and a docUrl pointing at a page that does not exist, while the same failure from the JavaScript engines came back as ATA1001; both now report the documented code, keyword and link. tests/test_native_error_codes.js holds the table against the enum in include/ata.h, so the two cannot drift apart silently.

• The error generator declined self-referencing schemas by emitting nothing for the reference, which accepted whatever that reference guarded: { properties: { foo: { $ref: "#" } }, additionalProperties: false } accepted { foo: { bar: false } } on that path. It now declines the schema outright and the validator falls back to an engine that answers it correctly. The entry-point agreement test covers the shape.

• ipv6 gave two different answers depending on which engine ran it, and neither was right. The compiled path refused an IPv4-mapped address such as ::ffff:192.168.1.1, the interpreted path accepted ::ffff:1.2.3.4.5, and both accepted a group of five hex digits like 12345::1. One implementation now answers for every engine, following RFC 4291, checked against Node's own net.isIPv6 and the suite's corpus.

• date-time refuses dates that do not exist. The check ran a regular expression for the shape and then handed the string to Date.parse, which rolls an out-of-range day into the next month, so 2026-02-30T00:00:00Z, 2026-02-29T00:00:00Z and 2026-12-31T24:00:00Z were all accepted. The month, the day count for that month in that year, the clock and the offset are now checked directly, per RFC 3339. Schemas that relied on the old leniency will see those values rejected.

• Data that points back at itself no longer exhausts the stack. A document with a cycle, which JSON text cannot express but an in-memory object graph can, threw RangeError: Maximum call stack size exceeded on the compiled path while the interpreted engine settled on an answer, so the two engines disagreed. Both now follow the same rule: a value already being checked against a schema is a fixed point and counts as satisfied, and a cycle no longer hides a real violation elsewhere in the document. Validation runs a fast pass that only counts depth and a guarded pass that runs when that depth is exceeded, so ordinary documents pay one integer operation per recursive call. Measured interleaved on a self-referencing schema: a four-node document 22.2 to 30.6 ns, a 200-node document 2077 to 1178 ns, non-recursive schemas unchanged at 3.8 ns. tests/test_cyclic_input.js holds all three engines to the same answers.

Performance

• ipv6 and hostname read the string once as well: 54.7 to 29.6 ns and 45.5 to 28.2 ns, interleaved medians. ipv6 no longer allocates two arrays per check; hostname keeps the answers of the expression it replaces, fuzzed over 300k strings with 0 mismatches.

• date-time reads the string once, with no regular expression, no date object and no allocation: 95.0 to 39.4 ns on a valid value with a Z, 103.8 to 45.3 ns with a numeric offset, interleaved medians. Fuzzed against a reference that spells out RFC 3339, with 0 mismatches over 300k strings; tests/test_formats_single_pass.js keeps both the predicate and the generated form on it.

• A constructed Validator is roughly three times smaller on the heap until it is used. The public methods and the Standard Schema entry moved from per-instance closures built in the constructor to memoized prototype accessors, and the JSON position cache is only allocated when the JSON text path first needs it. Measured per instance on a 10-key object schema, double-gc deltas over 2000 instances: 1.61 KB to 0.43 KB with a shared schema object, 2.33 KB to 1.12 KB when each instance owns its schema, 3.93 KB to 3.30 KB once compiled and used. Construction alone went from 1504 to 855 ns; construction plus first validate pays about 0.9 microseconds more, once, because the compile step's method assignments now go through a defining setter. The hot validate() path is unchanged, measured interleaved. Detached method references (const f = v.validate) still work; tests/test_lazy_instance.js pins the shape.

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

... (truncated)

Changelog

Sourced from ata-validator's changelog.

1.11.0 - 2026-08-31

Fixed

• The verdict methods answer the same question as validate() again. With coerceTypes, removeAdditional or a schema default in play, validate() ran the preprocess pass and isValidObject(), isValidJSON() and validateJSON() did not, so the same validator answered true from one and false from another for the same document: validate({ age: '26' }) accepted where isValidObject({ age: '26' }) rejected. Every path now runs the same pass. Verdict methods on a validator configured this way rewrite the input in place, as validate() already did, and the cost of the correction is 0.5 ns on isValidObject and 2.7 ns on isValidJSON, measured interleaved; validators without those options are unchanged. tests/test_verdict_preprocess.js holds all four methods to the same answers.

• The native engine's error codes no longer reach callers untranslated. A type failure answered by the addon came back as code: 3 with no keyword and a docUrl pointing at a page that does not exist, while the same failure from the JavaScript engines came back as ATA1001; both now report the documented code, keyword and link. tests/test_native_error_codes.js holds the table against the enum in include/ata.h, so the two cannot drift apart silently.

• The error generator declined self-referencing schemas by emitting nothing for the reference, which accepted whatever that reference guarded: { properties: { foo: { $ref: "#" } }, additionalProperties: false } accepted { foo: { bar: false } } on that path. It now declines the schema outright and the validator falls back to an engine that answers it correctly. The entry-point agreement test covers the shape.

• ipv6 gave two different answers depending on which engine ran it, and neither was right. The compiled path refused an IPv4-mapped address such as ::ffff:192.168.1.1, the interpreted path accepted ::ffff:1.2.3.4.5, and both accepted a group of five hex digits like 12345::1. One implementation now answers for every engine, following RFC 4291, checked against Node's own net.isIPv6 and the suite's corpus.

• date-time refuses dates that do not exist. The check ran a regular expression for the shape and then handed the string to Date.parse, which rolls an out-of-range day into the next month, so 2026-02-30T00:00:00Z, 2026-02-29T00:00:00Z and 2026-12-31T24:00:00Z were all accepted. The month, the day count for that month in that year, the clock and the offset are now checked directly, per RFC 3339. Schemas that relied on the old leniency will see those values rejected.

• Data that points back at itself no longer exhausts the stack. A document with a cycle, which JSON text cannot express but an in-memory object graph can, threw RangeError: Maximum call stack size exceeded on the compiled path while the interpreted engine settled on an answer, so the two engines disagreed. Both now follow the same rule: a value already being checked against a schema is a fixed point and counts as satisfied, and a cycle no longer hides a real violation elsewhere in the document. Validation runs a fast pass that only counts depth and a guarded pass that runs when that depth is exceeded, so ordinary documents pay one integer operation per recursive call. Measured interleaved on a self-referencing schema: a four-node document 22.2 to 30.6 ns, a 200-node document 2077 to 1178 ns, non-recursive schemas unchanged at 3.8 ns. tests/test_cyclic_input.js holds all three engines to the same answers.

Performance

• ipv6 and hostname read the string once as well: 54.7 to 29.6 ns and 45.5 to 28.2 ns, interleaved medians. ipv6 no longer allocates two arrays per check; hostname keeps the answers of the expression it replaces, fuzzed over 300k strings with 0 mismatches.

• date-time reads the string once, with no regular expression, no date object and no allocation: 95.0 to 39.4 ns on a valid value with a Z, 103.8 to 45.3 ns with a numeric offset, interleaved medians. Fuzzed against a reference that spells out RFC 3339, with 0 mismatches over 300k strings; tests/test_formats_single_pass.js keeps both the predicate and the generated form on it.

• A constructed Validator is roughly three times smaller on the heap until it is used. The public methods and the Standard Schema entry moved from per-instance closures built in the constructor to memoized prototype accessors, and the JSON position cache is only allocated when the JSON text path first needs it. Measured per instance on a 10-key object schema, double-gc deltas over 2000 instances: 1.61 KB to 0.43 KB with a shared schema object, 2.33 KB to 1.12 KB when each instance owns its schema, 3.93 KB to 3.30 KB once compiled and used. Construction alone went from 1504 to 855 ns; construction plus first validate pays about 0.9 microseconds more, once, because the compile step's method assignments now go through a defining setter. The hot validate() path is unchanged, measured interleaved. Detached method references (const f = v.validate) still work; tests/test_lazy_instance.js pins the shape.

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

... (truncated)

Commits

• 0ee5678 chore: bump to 1.11.0
• 9773b57 merge: single-pass date-time, ipv6 and hostname
• eb66231 perf: read ipv6 and hostname once, and give ipv6 one answer
• cab562d perf: read date-time once and refuse dates that do not exist
• 5bd6c51 merge: verdict methods agree with validate under preprocessing
• e8e57d1 fix: run the verdict methods through the same preprocess as validate
• 00a6e66 merge: native error codes and the self-ref decline
• 0a9f0bc fix: translate native error codes and decline self-referencing error codegen
• 0b120be merge: settle cyclic input on the compiled path
• d28c556 fix: settle cyclic input instead of exhausting the stack
• 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 #7.