src: create lazy json parser

[araujogui]

No description provided.

[nodejs-github-bot]

Review requested:

• @nodejs/gyp
• @nodejs/loaders
• @nodejs/startup

[JakobJingleheimer]

Is this related to #61641 ?

[araujogui]

Is this related to #61641 ?

Yeah, I decided to pivot. Since full JSON materialization is likely a performance bottleneck, I’m implementing a lazy JSON parser instead.

[anonrig]

We shouldn't return string from this. This would be extremely slow. We can use an enum of numeric values called JSONType, and to .type() == JSONType.Array

[anonrig]

Why limit the module name to only parser?

Suggested change

	const { Parser } = require('node:json_parser');
	const { JSONParser } = require('node:json');

[anonrig]

• Docs are missing.
• Tests handling each edge case (errors) are missing

[RafaelGSS]

As I said in the OpenJS Slack, I don't see value in it on the core instead of a userland module.

Considering there's no internal usage of it yet, it's just another module to handle fixes and security patches.

[araujogui]

As I said in the OpenJS Slack, I don't see value in it on the core instead of a userland module.

Considering there's no internal usage of it yet, it's just another module to handle fixes and security patches.

Just curious, what’s the line of reasoning for deciding whether something should be part of the core or not? Is that documented somewhere, or is it more of a case-by-case consensus?

[araujogui]

Just to be clear: this PR isn’t ready yet. I opened it to gather feedback before moving too far ahead.

[jsumners-nr]

As I said in the OpenJS Slack, I don't see value in it on the core instead of a userland module.
Considering there's no internal usage of it yet, it's just another module to handle fixes and security patches.

Just curious, what’s the line of reasoning for deciding whether something should be part of the core or not? Is that documented somewhere, or is it more of a case-by-case consensus?

In this sort of case, I'd say that it is due to the fact that the vast majority of people rely on the JSON built-in and would have to explicitly decide to use node:json and there isn't a clamor for a JSON replacement in core that I am aware of. But I'm just guessing.

[RafaelGSS]

Just curious, what’s the line of reasoning for deciding whether something should be part of the core or not? Is that documented somewhere, or is it more of a case-by-case consensus?

That's actually a good question, and I have been discussing with TSC a few times to clarify somewhere what makes a module prone to be on nodejs built-in and what not. Unfortunately, that's not easy to define and change from time to time - for instance, most modules that are now on Node.js built-in wouldn't be here if they were proposed 5 years ago.

I concur with @jsumners-nr on it. We don't have evidence that the community needs that, nor do we have a plan to use that on Node.js internals, for instance, to improve performance somehow. Usually, modules that get inserted on Node.js built-in follow one or more of these bullet points:

• The community uses it widely, and the userland packages aren't being actively maintained, which poses a significant security risk.
• We currently have an internal usage for that, and we are just exposing the module, so technically, we won't add more maintenance burden on it.
• There are a group of folks that volunteer to maintain the module

Please, have in mind that more modules often mean more maintenance and more attack surface. We are currently overwhelmed with security reports, and adding a new module without matching the above bullet points will only increase the maintenance on Node.js members and the amount of security reports the security triage team needs to deal with.