Repository navigation
JSON Schema validation in Node.js core #62598
Description
Activity
This sounds interesting! Having built-in validation for
node.config.json
against its existing schema would be a practical first step. Looking forward
to seeing the benchmarks.Reacted by João Ferreira, Marco Ippolito and Mert Can AltinReacted by Mert Can AltinWould like to see the validation for node.config.json
Reacted by Mert Can Altin and Matteo CollinaIt is sad to see that only ajv is the popular library for json-scema validation. I would like to have native json-schema validation in node itself.
Reacted by Mert Can AltinReacted by Domagoj VukovicWould like to see the validation for node.config.json
I've discussed this with @Qard as well, starting with node.config.json validation sounds like a great first step.
I'll work on a draft PR for thatReacted by SukeshP1995 and Gürgün DayıoğluWe've already discussed it privately, but I think this is worth at least evaluating having it in core. The current design seems to align very well with our performance efforts, even relying on some libraries we already depend on. So the lift to integrate this seems low while the benefit seems high given how many apps need to do input validation and the cost it can have. I also think it's a fairly mechanical need and not like typical libraries where design opinions could be involved--jsonschema works a particular way, and it's a widely accepted standard, so having it in core I think makes sense.
Reacted by Mert Can Altin and maryReacted by SukeshP1995I opened a PR for node.config.json #62603
I think
node.config.jsonwould be a good use case for this since it has a proper schema. Forpackage.jsonit makes less sense - it's in a performance sensitive path, all the fields are optional, we generally only parse each file once, or lazy parse as much as possible (for imports/exports), and the happy path assumes all fields if present are valid - adding a round of eager schema validation would defeat the optimizations or introduce regressions e.g. when the fields are invalid, most of them have always been silently ignored.The strongest use case would be a public module for validating untrusted input. Though that would require the underlying implementation to have e.g. good DoS resistance and proper security handling process first.
Reacted by Mert Can Altin and Andrew Johnston8 remaining items
I'm very happy right now. I just saw @sheplu 's work on validation, and I'm really glad that we'll be solving this problem and collaborating on it with such a great team, I guess we made a node:json or schema team :D
Let me give you a quick update on the current direction. As you may have seen in the issue, we already have ongoing work for node.config.json (#62603). After that, we were planning to move toward an API design, similar to @sheplu's work (#62927 (comment)).
Now, working together on an API design and discussing it would be great. In general, we've received these suggestions this api names from the community:node:schema, focused on JSON Schemanode:jsonschema, more specificnode:json, broader, covering both parsing and validation together (ata already vendors simdjson)Looking forward to hearing your thoughts on this.
Reacted by Guilherme Araújo, Vinicius Lourenço, Stephen Belanger, Guillaume Humbert and Andrei KarushevI don't think we should be adding 3 new subsystems to core for this.
Reacted by Vlad, Marco Ippolito and Chengzhong Wunode:schema, focused on JSON Schemanode:jsonschema, more specificnode:json, broader, covering both parsing and validation together (ata already vendors simdjson)I think I explained it incorrectly, these were name suggestions. I didn’t mean three separate layers, I meant what the API name should be.
Reacted by Stephen BelangerI am glad that I am not the only one finding interesting / nice to have a solution to validate json directly in core. Trying to think about the next steps, I think that
node:jsonornode:jsonschemawould be better (node:jsonschemafor me) which would allow for any kind of "validator" something that would benode:jsonschema/validator.@mertcanaltin are you ok if we use the PR I opened to see and get feedback from the publicly facing part of the API - or do we want all the discussion here?
node:jsonschemaworks for me. The subpath idea (node:jsonschema/validator) is nice, leaves room for future extensions without locking the surface early.I'd lean toward keeping API direction here on #62598 since it's on the TSC agenda and the broader group is subscribed. Your PR (#62927) is a useful concrete reference for what a prototype looks like.
Once the TSC has weighed in on whether one module makes sense in core at all, we can sync on the API design and whether your PR or a fresh one ends up being the implementation track.
Reacted by Jean Burellier, Otman and Stephen BelangerShould this issue still stay on the TSC agenda? This has been on 3 TSC meetings so probably has served its purpose as FYI?
Reacted by Mert Can AltinShould this issue still stay on the TSC agenda? This has been on 3 TSC meetings so probably has served its purpose as FYI?
Thanks for checking @joyeecheung.
Agree it has served its purpose. we have direction on naming (node:jsonschema, possibly with subpaths) and a first concrete target (node.config.json in #62603). @sheplu has a public API prototype in #62927.
Happy to take it off the agenda. I'll bring the implementation work back to the TSC when there's something concrete to decide on, either through this issue or the PRs.
Somehow off-topic, but here are fresh news that may interest contributors about the current state of JSON Schema spec with an article wrap-up of the JSON Schema Conf containing a few interesting points regarding the overall stability of the spec and the multiple-drafts situation:
https://json-schema.org/blog/posts/apidays-paris-2025-recap
The conference opened with Jason Desrosiers @jdesrosiers, JSON Schema Specification and Tooling Architect at Hyperjump Software, Inc, presenting “JSON Schema v1 — No More Drafts.”
The session explored the future direction of JSON Schema and addressed one of the ecosystem’s longest-standing concerns around drafts, versioning, and compatibility. The proposed v1 direction introduces a more stable and predictable evolution model aimed at reducing migration friction while giving users greater confidence in long-term schema maintenance.
Reacted by Jean Burellier and Mert Can AltinHere's the slides from that talk, https://docs.google.com/presentation/d/1ajXlCQcsjjiMLsluFIILR7sN5aDRBnfqQ9DLbcFbqjI/edit?usp=sharing
Reacted by Bruno Heridet, Mert Can Altin and Jean BurellierThis issue 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.
What is the problem this feature will solve?
Hi all,
I wanted to open a discussion about whether JSON Schema validation could be a useful addition to Node.js core.
Current state
node.config.json(experimental) uses hand-written type checking against a JSON Schema 2020-12 definition generated from C++ option metadatapackage.jsonparsing uses simdjson but has no schema validation, fields are extracted structurallydeps/npm(Ajv)Potential use cases
node.config.jsonagainst its own schema properlypackage.jsonfields (opt-in, non-breaking)node:jsonschema) so userland doesn't need to pull in external validatorsContext
I've been working on a project in this area, ata-validator, a JSON Schema validator built on simdjson and RE2. It currently passes 96.9% of the official JSON Schema Test Suite (Draft 2020-12) and falls back to a pure JS engine when native bindings aren't available.
I'm not proposing to land it as-is, I'd love to hear from the group first:
Happy to share benchmarks or more details if this sounds worth exploring.
fyi @Qard
What is the feature you are proposing to solve the problem?
A built-in JSON Schema validator, potentially exposed as node:jsonschema, that could also be used internally for validating node.config.json and other configuration files.
This would provide Node.js users with a fast, native JSON Schema (Draft 2020-12) validation capability without needing external dependencies.
What alternatives have you considered?
Continuing with hand-written validation for each config format individually,
doesn't scale as more config formats are added
Bundling an existing JS-based validator like Ajv into core, lacks native performance benefits
Leaving JSON Schema validation entirely to userland