deps: add ata JSON Schema validator for node.config.json

[mertcanaltin]

Adds ata-validator (v0.10.3) to validate node.config.json against its JSON Schema before parsing.

Clear error messages for invalid config instead of generic "Invalid value" errors.

Example output:

Invalid configuration in node.config.json: /nodeOptions/import: expected exactly one oneOf match, got 0

What's included:

• deps/ata/ with ata-validator built using ATA_NO_RE2 (no extra dependencies, only simdjson which is already in core)
• Schema validation step in node_config_file.cc before existing parsing
• process.versions.ata

Spec compliance:

• 98.5% Draft 2020-12 test suite (1172/1190)
• 95.3% @exodus/schemasafe test suite
• $dynamicRef / $anchor: 42/42 (100%)

Security:

• Recursion depth guard for circular $ref
• __proto__ safe const/enum comparison
• Date format range validation
• OSS-Fuzz submitted, 283/283 JSONTestSuite passing

refs: #62598

[nodejs-github-bot]

Review requested:

• @nodejs/tsc
• @nodejs/gyp
• @nodejs/security-wg

[codecov]

Codecov Report

❌ Patch coverage is 81.08108% with 28 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.72%. Comparing base (80e0f14) to head (a68e675).
⚠️ Report is 924 commits behind head on main.

Files with missing lines	Patch %	Lines
src/node_options.cc	82.11%	15 Missing and 7 partials ⚠️
src/node_config_file.cc	76.19%	0 Missing and 5 partials ⚠️
lib/internal/options.js	66.66%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #62603 +/- ##
==========================================
+ Coverage 89.65% 89.72% +0.06% 
==========================================
Files 708 708 Lines 220413 220302 -111 Branches 42275 42277 +2 ==========================================
+ Hits 197607 197657 +50 + Misses 14658 14476 -182 - Partials 8148 8169 +21 

Files with missing lines	Coverage Δ
src/node_metadata.cc	92.95% <100.00%> (+0.10%)	⬆️
src/node_options.h	97.98% <ø> (ø)
lib/internal/options.js	96.05% <66.66%> (+49.46%)	⬆️
src/node_config_file.cc	75.26% <76.19%> (-8.70%)	⬇️
src/node_options.cc	85.96% <82.11%> (+9.35%)	⬆️

... and 23 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[juanarbol]

IMHO this is a bit too much, an extra dep for a schema parser inside Node.js (not to mention that is not even v1.x)

This is not a blocker, this is just my personal opinion

[mertcanaltin]

That's a fair concern. The dependency is intentionally minimal, it only uses simdjson which is already in core (no new external dependencies since it's built with ATA_NO_RE2).

On the version, you're right it's pre-1.0, but it already passes 96.9% of the official JSON Schema Test Suite. Happy to work toward 1.0 if that's a requirement.

[TheOneTheOnlyJJ]

Maybe ata could also be exposed to JS userland as an API if it ends up being vendored in?

[mertcanaltin]

Yes, that's the plan! The initial PR focuses on node.config.json validation as a starting point, but exposing it as a public API is the natural next step. We discussed this in #62598, Joyee mentioned it would be the strongest use case.

The main prerequisite is getting the security story solid first, we've already submitted to OSS-Fuzz and all 283 nst/JSONTestSuite tests are passing.

[ChALkeR]

@mertcanaltin check also https://www.npmjs.com/package/@exodus/schemasafe testsuite

[mertcanaltin]

Thanks @ChALkeR, I ran the schemasafe test suite against ata (draft2020-12):

95.3% pass rate, 1103/1157, 59 skipped (remote refs).

Main gaps are unevaluatedProperties/Items annotation tracking, some $ref URI edge cases (URN, absolute-path), grapheme counting in minLength/maxLength, and a few optional format semantics.

Running the suite also helped me catch a few things I fixed since: recursion depth guard for circular $ref, proto handling in const/enum, and date format range checks.

$dynamicRef is fully passing now (42/42). Working on the rest.

[Qard]

CI says:

../../src/node_config_file.cc:2:10: fatal error: 'ata.h' file not found
2 | #include "ata.h"
| ^~~~~~~

[Qard]

While it is a non-trivial amount of C++, it is all neatly contained in the external ata dependency where we can trivially iterate on any correctness requirements if there's any of the remaining spec features folks think are essential. The actual integration surface area is extremely minimal and straightforward.

I think it looks great. Excellent work! 👏🏻

[mertcanaltin]

thanks for review @Qard, I some conflicts solved, if have available time, can you review again ?

[lemire]

Looks fine to me but I recommending adding more tests. Currently, the builtin tests are somewhat mininal.

[mertcanaltin]

Thanks @lemire, added more test coverage, type mismatches for boolean, number, array, and nested array items, plus positive tests for valid configs and empty objects.

[avivkeller]

Can you add an update script?

[mertcanaltin]

Can you add an update script?

I added thanks @avivkeller

[ChALkeR]

@mertcanaltin could it notice mistakes like #61595?

[mertcanaltin]

@marco-ippolito I removed unused codes 0d17c47, 9b19d8b

[joyeecheung]

I feel that as a 3000+ LOC deps this is a bit of an overkill to vendor in for this use case - node.config.json isn't really on a path that would benefit all that much from it compared to how it's currently implemented. The few extra ns gain is a drop in the ocean in the picture of start up time of dozens if not hundreds of ms; It's part of the trusted configuration that's outside our threat model so the security claim is out of scope. Until ata itself is battle tested enough in the wild by being used by more users, we are introducing maintenance burden for being the most common entry point where people are going to try out this new library, this means:

1. When people notice bugs, it's likely they will be mostly reported to Node.js core and fixed here instead of being noticed elsewhere first. It means we would effectively take over ata's issue triage load
2. Many security reporters would report vunerabilities they find in Node.js's dependencies even though they are not applicable to Node.js's use cases (take V8's type confusion vulnerabilities for example). This leads to an issue similar to 1 but even more serious because Node.js security triagers are even more overloaded by spams
3. When the iteration of a library effectively happens in Node.js core, it will be coupled into Node.js's semver and introduce backport churn for releasers.

Since ata is also available as an npm package, I'd be more comfortable if ata is used by other projects e.g. server frameworks in paths where its stated goal - a more secure and performant validator - actually matters, and get this goal battle tested, bugs reported and fixed in ata through wider adoption, before vendoring it inside Node.js core. At that point using node.config.json would be mostly a drive-by, but at least we know for sure that the library can actually justify being in core as a input validator as proposed in #62598 instead of staying as an overkill for a use case where the gain is negligible.

[mertcanaltin]

Thanks @joyeecheung, the maintenance burden point is the strongest one and fair.

Some background: ata is in OSS-Fuzz, passes 98.5% of Draft 2020-12 suite, 95.3% of @exodus/schemasafe, 283/283 nst/JSONTestSuite. Dependency is minimal, ATA_NO_RE2 so only simdjson (already in core).

three maintainers (@Qard, @lemire, @anonrig) approved after looking at the code.

you are right on the userland adoption point, that's the bar I have not met yet. Fastify integration work is in progress (compatibility-focused, and perf), the plan was wider adoption before core. This PR was a bit early.

Happy to convert this to draft and revisit once ata reaches 1.0 and has real-world traction. What would count as sufficient testing for you? That bar would help me plan the path back.

[joyeecheung]

It's hard to say what would be a good threshold for something to be considered mature, or whether a sharp threshold even exists or is it just going to be a very big grey area before it gets there; but I think usually when it reaches there this would be non-disputable for most people you ask; one possible measurement is npm download counts and dependent statistics e.g. this - this has the bias towards certain categories of libraries, but then this is in the category of libraries where these stats would skew towards, if you take a look at ajv's stats. Another possible measurement is simply time, the longer it's depended on by people the more issues will be uncovered and fixed. If the justification for a 3000+ LOC deps is that "it will be used for input validation", then IMO there needs to be some evidence that users actually prefer it over ajv because it's otherwise hard to explain to our users why we are adding a relatively unknown library that have not been battle tested instead of a well known, battle tested one whose API is already depended on by many.

[mertcanaltin]

I’ll be focusing on the user side (starting with the Fastify integration) I’m marking this as a draft, and I’d like to thank everyone again for all the comments and feedback.

[TheOneTheOnlyJJ]

Hey @mertcanaltin, I just opened rjsf-team/react-jsonschema-form#5052 to try to help you on the user validation front.

I believe a highly performant JSON Schema validation solution vendored into Node out of the box would be valuable (at least in my projects, it would).

Integrating with RJSF would increase the number of monthly ata downloads on npm and allow for faster, effective user validation of the library. For reference, the current RJSF AJV validator gets almost 1M downloads/month. Feel free to interact with the community there; the maintainers are very cooperative and would certainly help with a potential integration. I see it as a good step towards getting ata into Node eventually.

To prevent this discussion from going off-topic, I suggest we continue the discussion about this in the above-linked issue.

[mertcanaltin]

Really appreciate this @TheOneTheOnlyJJ, RJSF is a great direction, I will continue the discussion on the linked issue.

[github-actions]

This pull request has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

[TheOneTheOnlyJJ]

This went stale. Unfortunate but understandable.

Maybe a good path forward is to wait for JSON Schema v1 to be released and pick it up again from there?
More information on JSON Schema v1: mention in blog post, presentation slides.

ata is now stable, and the JSON Schema standard will also become more stable from v1 onwards.
Of course, ata would need yet another update to support it once that happens.

Furthermore, given that the TC39 linear pattern matching proposal is advancing, and once reaching Stage 4 will most likely be implemented using RE2 in V8 (it already is, under an experimental flag).
That would also make it possible to share the RE2 library from V8 instead of separately vendoring it in exclusively for ata, so we could get it for free and also get the native benefits without having to go through the native-JS boundary.

What do you think about this approach, @mertcanaltin?

Given all of the above, this PR just looks like it was ahead of its time.

Edit: This also concerns #62927, maybe even more than this.

[mertcanaltin]

ata is now stable, and the JSON Schema standard will also become more stable from v1 onwards.
Of course, ata would need yet another update to support it once that happens.

Yes, we can support it quickly.

Furthermore, given that the TC39 linear pattern matching proposal is advancing, and once reaching Stage 4 will most likely be implemented using RE2 in V8 (it already is, under an experimental flag).
That would also make it possible to share the RE2 library from V8 instead of separately vendoring it in exclusively for ata, so we could get it for free and also get the native benefits without having to go through the native-JS boundary.

This sounds good to we, ata already using ATA_NO_RE2 for compile but absolutly Builtin better more for dependen

Some news on my side:

ata, as you said, is now version 1.3.0, downloads 4k monthly, Bowtie now, so the spec numbers come from someone other than me. RJSF merged a runtime and a precompiled validator, and Fastify lists it as an alternative validator.
full draft 2020-12 suite with nothing skipped is 1285/1290, Draft 7 is 911/922, I am continuing to develop stable for trust