chore: bump ata-validator from 0.5.1 to 1.14.1

[dependabot]

Bumps ata-validator from 0.5.1 to 1.14.1.

Release notes

Sourced from ata-validator's releases.

v1.14.1

The parse option added in 1.14.0 was missing from the TypeScript declarations for toStandaloneModule, so passing it failed to typecheck.

v1.14.0

removeAdditional now strips every level. It removed unknown keys from the root object and stopped there, while the interpreted path recursed, so the same schema and the same document produced opposite verdicts depending only on whether the runtime allowed code generation. A nested request body that Fastify's default validator accepts was rejected. Both paths now strip everywhere the schema describes, and a test compares them.

Standalone modules can emit parse(). Pass { parse: true } to toStandaloneModule and the module also exports a function that validates and returns a copy of the input holding only the properties the schema declares. It reads the keys the schema names rather than enumerating the input and deleting what does not belong, so it costs the schema's size instead of the document's, and it leaves the caller's object untouched. Measured at 5.2x the delete-based strip on a seven-field object with one nested level.

It is emitted only where the copy is provably exact. A $ref, a composition, patternProperties, an additionalProperties schema or an array of objects all leave the allowed key set outside this node's knowledge, and those schemas get no parse() rather than a sanitiser that quietly drops something the schema allows. Off by default, so emitted modules keep their current size.

v1.13.2

Two fixes and one cost removed.

The tier-0 validator that answers a fresh instance's first calls accepted NaN and Infinity for number, so a validator could change its mind about the same value between its first call and its third, and permanently under a blocked-codegen CSP. Non-finite numbers are now rejected on every path, cold and warm, and a new engine-agreement test holds the line.

A rejection on the buffer path no longer pays a second full walk of the document when the bytecode plan has already decided: reject cost now matches accept cost at every payload size measured, guarded by a ratio test in CI.

The aot entry's type declarations accept the same schema arrays the static methods accept.

1.13.1

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.

1.13.0

Changed

• The default browser bundle stops carrying the AOT emitters. lib/aot.js has promised a browser stub via the package.json browser field since the fs-free build, but the mapping was never actually in the field, so every browser bundle shipped the emitters and the embedded safe-regex engine source they pull in, along with the native walker's routing table that only matters when the native addon loads. Both now map to stubs. Emitting validators in a browser still works, through the new ata-validator/aot entry, and the Validator.bundle* statics in a browser bundle throw a message that points there; Validator.loadBundle keeps working in the default bundle, since loading a bundle somebody already built is a runtime act. Measured with the schema-benchmarks rolldown pipeline: minified and gzipped 73,491 to 64,812 bytes, 11.8 percent smaller. The browser-imports guard now bans a token from each excluded file so the mapping cannot regress silently.

Added

• ata-validator/aot: the standalone emitters (toStandalone, toStandaloneModule, bundle, bundleStandalone, bundleCompact, loadBundle) as an explicit, typed import. In Node it is the same module the statics use; in a browser it is the way to opt back into emission without paying for it on pages that never emit.

1.12.1

Fixed

• One format violation reports one error. The error path turns each failing statement of a format check into an error push, and it kept going after pushing, so a single bad value collected one identical error per statement it failed: twelve for date-time on a short string, five for time, two for uuid and hostname. The check now leaves the format block on the first failure. Verdicts are unchanged; only the duplicate copies of the same error are gone. tests/test_format_single_error.js holds every built-in format to exactly one error across 25 invalid values.

1.12.0

Performance

• date-time stopped asking every character where it sits. The scan tested each of nineteen positions against the separator indices before checking the digit; the separators are now read directly by index and each digit becomes its value in the same read that validates it, so the field numbers cost nothing extra. 40.8 to 19.5 ns on a valid value, medians across separate processes. Same answers as before on every month, day and clock boundary and under 150k random mutations.

• uuid reads the four hyphens by index and the 32 hex digits in five runs with fixed bounds, instead of a case-insensitive regular expression. A digit is one unsigned compare and a letter one more after folding case with a single OR. 48.4 to 35.1 ns; 300k mutated and random strings against the old expression with 0 mismatches.

• time reads fixed positions the same way instead of running a regular expression: 15.6 to 12.1 ns, and 200k mutations against the old pattern with 0 mismatches.

... (truncated)

Changelog

Sourced from ata-validator's changelog.

Changelog

All notable changes to ata-validator are documented here. The format follows Keep a Changelog, and this project adheres to semantic versioning.

1.17.2 - 2026-09-13

Changed

• new Validator(schema) no longer walks the schema. Normalization (the draft-07 rewrites, nullable, format removal under assertFormat: false) and the scan that decides whether any of it is needed now run on the first read of the schema, which is the first compile. Construction is the instance and its fields. Measured on the schema-benchmarks product schema built fresh each time: 4.28 to 0.91 µs; with the @ata-project/keywords wrapper (0.3.1, which reads the schema lazily too) 6.70 to 2.81 µs. Nothing observable changes for a schema that is used: the same normalized document reaches the engines, and the identity cache, keywords, assertFormat and source options behave as before. tests/test_lazy_normalization.js counts property reads on the schema during construction and holds them at the dialect lookup alone.

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.

... (truncated)

Commits

• 2ce6f50 fix: the parse option is in the standalone module types
• 1298208 chore: bump to 1.14.0
• 6746034 feat: aot modules can emit parse(), a sanitising copy of the input
• 0f92822 fix: removeAdditional strips every level, not just the root
• d32425a chore: bump to 1.13.2
• 42dec15 fix: tier-0 verdicts reject non-finite numbers like every other engine
• 05316a9 perf: a decisive rejection on the buffer path skips the second walk
• 4d64e99 fix: aot entry accepts the same schema arrays the statics accept
• cb95f9f chore: bump to 1.13.1
• a6ec1e1 fix: no stderr from re2 for patterns outside its subset
• 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 #10.