chore: bump ata-validator from 0.5.1 to 1.17.1

[dependabot]

Bumps ata-validator from 0.5.1 to 1.17.1.

Release notes

Sourced from ata-validator's releases.

v1.17.1

Changed

• The rejection object behind a failing validate() is an instance of a class with prototype accessors rather than an object literal that defined a getter and a closure on every rejection. Same shape, same laziness, same caching; JSON.stringify still sees the errors.
• Declaration-order sorting of short error lists is a stable in-place insertion sort over the integer keys, with no comparator and no index array. Measured on the raw error list of the schema-benchmarks product schema, 15 errors: 1.49 to 1.10 µs; through the Standard Schema bridge 2.02 to 1.63 µs. Since 1.16.2 that row has gone from 3.30 to 1.63 µs on the same machine, and in the schema-benchmarks harness itself standard invalid went from 3.57 to 1.44 µs (60 percent less), every other row within noise.

Fixed

• validateJSON() reports errors in schema declaration order, as validate() does. The text path enriched errors in emission order, so the first error could differ between the two entry points for the same document.
• An instance built with options no longer answers a later new Validator(sameSchema) without options. The identity cache was seeded by every instance, so a validator created with richErrors: false or coerceTypes could be handed back to a caller that asked for the defaults.

Suite: Draft 2020-12 1299 of 1299, draft 7 927 of 927, v1 1133 of 1133.

v1.17.0

Changed

• Errors are put in schema declaration order by an integer computed when the schema is compiled, not by walking each error's schemaPath at read time. The rank of a path is its pre-order position in the schema tree, which is exactly the order the old array-of-indexes comparison produced; the code generator writes that position into each error literal (_o, an internal field), the reader compares integers, and a list that already arrives in order is returned without sorting or allocating.
• The Standard Schema bridge caches parsed issue paths per instancePath string (bounded, entries frozen).
• Measured on the schema-benchmarks harness locally, before and after on the same machine: standard invalid 3.57 to 2.83 µs (21 percent less); every other row within noise. Raw error list of that schema, 15 errors: 1.88 to 1.50 µs; through the Standard Schema bridge 3.30 to 1.99 µs. Verdict paths are untouched.
• richErrors: false keeps the v0.14 key set: the ordering field is dropped from that shape.

Suite: Draft 2020-12 1299 of 1299, draft 7 927 of 927, v1 1133 of 1133.

v1.16.2

Fixed

• A schema with unevaluatedProperties or unevaluatedItems reported every failure as one placeholder error, { code: 'unevaluated', message: 'unevaluated property or item' }, with no keyword and no instancePath. The generated code answers the verdict for these schemas but the error generator declines them, and the error path then fell into a stub instead of the interpreted engine, which reports them correctly. A wrong type, a missing required property, a bad format or an enum miss under a root unevaluatedProperties: false all came back as that one line. Failing data is now re-validated by the interpreted engine on that path. Verdicts were never affected. Found by a user comparing error output on a generated config schema. tests/test_unevaluated_error_path.js holds the generated-code path to the interpreter's errors on five shapes, in all three engine modes.

Suite: Draft 2020-12 1299 of 1299, draft 7 927 of 927, v1 1133 of 1133.

v1.16.1

Fixed

• A custom format (formats: { name: fn }, or addFormat on the compat class) next to a shape the combined code generator declines, such as an anyOf sibling, threw _uf_<name> is not defined on the first invalid document instead of reporting the format error. The error-path code generator emitted the call to the format checker without binding it; it now takes the checkers as bound parameters like the other two entry points. Verdicts were never affected, only the error path, and only on that combination. Present since custom formats were added; caught by the 1.16.0 clean-install check. tests/test_user_format_error_path.js covers it, and the compat parity corpus has the scenario.

Suite: Draft 2020-12 1299 of 1299, draft 7 927 of 927, v1 1133 of 1133.

v1.16.0

Added

• Custom keywords. new Validator(schema, { keywords: { name: definition } }) registers keywords with a validate(value, data, parentSchema) function, a compile(value, parentSchema) factory, or a macro(value, parentSchema) that returns a schema applied in place. A definition can name the JSON Schema type it applies to. A schema that uses a registered keyword runs on the interpreted engine, so anyOf, not, $ref and the other applicators keep their meaning around the custom check; the compiled engines, the tier-0 plan and the native walker are routed away from such schemas, and the AOT emitters refuse them instead of emitting a module that would ignore the keyword. See docs/custom-keywords.md.
• ata-validator/compat covers the reference class's surface: compileAsync, removeSchema, validateSchema against the vendored meta-schemas, addFormat in its four forms, addKeyword in the validate, compile and macro forms plus the bare-name form, addVocabulary, getKeyword, removeKeyword, errorsText, addMetaSchema, ajv.errors and ajv.opts; and the constructor options allErrors, useDefaults (off by default, as in the reference), coerceTypes, removeAdditional, verbose, validateFormats, validateSchema, formats, keywords and schemas. A schema with no $schema is read as draft-07.
• The shim reports errors in the reference's shape and order: keywords in evaluation order rather than declaration order, the failing branches before an anyOf or oneOf, each bad property name with its own errors and a propertyNames error, items before contains and an if error after a failed then/else under allErrors, draft-07 dependencies named as such, and with allErrors off the first failing keyword's whole group. tests/test_ajv_parity.js runs 32 scenarios of real consumer call shapes through both implementations and compares the results field by field.

Changed

• ata-validator/compat refuses what it cannot honour instead of accepting it: $data: true throws at construction, a code-only keyword throws at addKeyword, and the reference's formats plugin throws with a note that its formats are built in.

Suite: Draft 2020-12 1299 of 1299, draft 7 927 of 927, v1 1133 of 1133, identical with code generation blocked.

... (truncated)

Changelog

Sourced from ata-validator's changelog.

1.17.1 - 2026-09-13

Changed

• The rejection object behind a failing validate() is an instance of a class with prototype accessors rather than an object literal that defined a getter and a closure on every rejection. Same shape, same laziness, same caching; JSON.stringify still sees the errors.
• Declaration-order sorting of short error lists is a stable in-place insertion sort over the integer keys, with no comparator and no index array. Measured on the raw error list of the schema-benchmarks product schema, 15 errors: 1.49 to 1.10 µs; through the Standard Schema bridge 2.02 to 1.63 µs. Since 1.16.2 that row has gone from 3.30 to 1.63 µs on the same machine, and in the schema-benchmarks harness itself standard invalid went from 3.57 to 1.44 µs (60 percent less), every other row within noise.

Fixed

• validateJSON() reports errors in schema declaration order, as validate() does. The text path enriched errors in emission order, so the first error could differ between the two entry points for the same document.
• An instance built with options no longer answers a later new Validator(sameSchema) without options. The identity cache was seeded by every instance, so a validator created with richErrors: false or coerceTypes could be handed back to a caller that asked for the defaults.

1.17.0 - 2026-09-13

Changed

• Errors are put in schema declaration order by an integer computed when the schema is compiled, not by walking each error's schemaPath at read time. The rank of a path is its pre-order position in the schema tree, which is exactly the order the old array-of-indexes comparison produced; the code generator now writes that position into each error literal (_o, an internal field), the reader compares integers, and a list that already arrives in order is returned without sorting or allocating. Errors without a position (an appended custom-keyword error, a path into another document) keep their place next to the error before them. The ordinal logic lives in lib/schema-order.js; tests/test_error_order_ordinal.js holds the ordinal to the array rank on a set of paths and holds the public error order unchanged.
• The Standard Schema bridge caches parsed issue paths per instancePath string (bounded, entries frozen), instead of splitting the string for every issue of every rejection.
• Measured on the schema-benchmarks harness locally, before and after on the same machine: standard invalid 3.57 to 2.83 µs (21 percent less); every other row within noise. On the raw error list of that schema, 15 errors: 1.88 to 1.50 µs; through the Standard Schema bridge 3.30 to 1.99 µs. Verdict paths are untouched.
• richErrors: false keeps the v0.14 key set: the ordering field is dropped from that shape.

1.16.2 - 2026-09-12

Fixed

• A schema with unevaluatedProperties or unevaluatedItems reported every failure as one placeholder error, { code: 'unevaluated', message: 'unevaluated property or item' }, with no keyword and no instancePath. The generated code answers the verdict for these schemas but the error generator declines them, and the error path then fell into a stub instead of the interpreted engine, which reports them correctly. A wrong type, a missing required property, a bad format or an enum miss under a root unevaluatedProperties: false all came back as that one line, so anything mapping errors by keyword and path saw nothing useful. Failing data is now re-validated by the interpreted engine on that path, as it already was without the native addon for other declined shapes. Verdicts were never affected. Found by a user comparing error output on a generated config schema. tests/test_unevaluated_error_path.js holds the generated-code path to the interpreter's errors on five shapes, in all three engine modes.

1.16.1 - 2026-09-12

Fixed

• A custom format (formats: { name: fn }, or addFormat on the compat class) next to a shape the combined code generator declines, such as an anyOf sibling, threw _uf_<name> is not defined on the first invalid document instead of reporting the format error. The error-path code generator emitted the call to the format checker without binding it; it now takes the checkers as bound parameters like the other two entry points. Verdicts were never affected, only the error path, and only on that combination. Present since custom formats were added; caught by the 1.16.0 clean-install check. tests/test_user_format_error_path.js covers it.

1.16.0 - 2026-09-12

Added

• Custom keywords. new Validator(schema, { keywords: { name: definition } }) registers keywords with a validate(value, data, parentSchema) function, a compile(value, parentSchema) factory, or a macro(value, parentSchema) that returns a schema applied in place. A definition can name the JSON Schema type it applies to. A schema that uses a registered keyword runs on the interpreted engine, so anyOf, not, $ref and the other applicators keep their meaning around the custom check; the compiled engines, the tier-0 plan and the native walker are all routed away from such schemas, and bundleStandalone refuses them instead of emitting a module that would ignore the keyword. Verdict paths (isValidObject, isValidJSON) agree with validate(). A keyword definition with none of the three forms throws, so a code-only definition is never accepted quietly.
• ata-validator/compat covers the reference class's surface: compileAsync, removeSchema (by key, by object, by RegExp, or everything), validateSchema against the vendored meta-schemas, addFormat in its four forms, addKeyword in the validate, compile and macro forms plus the bare-name form, addVocabulary, getKeyword, removeKeyword, errorsText, addMetaSchema, ajv.errors and ajv.opts; and the constructor options allErrors, useDefaults (off by default, as in the reference), coerceTypes, removeAdditional, verbose, validateFormats, validateSchema, formats, keywords and schemas. compile throws schema is invalid: ... on a schema the meta-schema rejects, and caches by schema object. A schema with no $schema is read as draft-07, which is what require('ajv') does.
• The shim reports errors in the reference's shape and order: keywords sorted the way the reference evaluates them rather than in declaration order, the failing branches before an anyOf or oneOf, each bad property name with its own errors and a propertyNames error, items before contains and an if error after a failed then/else under allErrors, draft-07 dependencies named as such, and with allErrors off the first failing keyword's whole group. tests/test_ajv_parity.js runs 32 scenarios of real consumer call shapes through both implementations and compares the results field by field; the reference is a devDependency and never ships.

Changed

• ata-validator/compat refuses what it cannot honour instead of accepting it: $data: true throws at construction, a code-only keyword throws at addKeyword, and the reference's formats plugin throws with a note that its formats are built in.

1.13.1 - 2026-09-06

Fixed

• The native engine stops printing to stderr for patterns outside RE2's subset. A pattern with lookahead or a backreference is an expected input, not a fault: construction is probed, and the JavaScript engines answer for the pattern instead. RE2 logged every such probe to stderr anyway, so a schema carrying zod's email pattern printed two C++ error lines on compile while validating correctly. RE2 is now constructed with logging off; verdicts are unchanged.

... (truncated)

Commits

• f2f47ce perf: rejection class and in-place sort; validateJSON order and identity cach...
• a4c2c21 perf: declaration order by a compile-time ordinal, cached issue paths
• 6da9d25 fix: real errors for unevaluated schemas on the generated-code path
• 44c9b67 fix: bind custom formats on the error codegen path
• 44fe4c1 docs: date the 1.16.0 changelog entry
• 50a87cd docs: list the unplugin package under framework integrations
• cb990e0 feat: custom keywords and the full ajv compat surface
• b7a0a92 chore: bump to 1.15.0
• 86b1ed5 fix: uri, iri, idn-email and the leap second in time and date-time
• 315d4fa fix: formats that were missing, wrong or on one engine only
• 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 #11.