JSON is a stable interchange format, and for that reason we’ve got a huge base of tooling that uses and emits it. It’s all interoperable because there is just that one syntax.
So if you say “add JSON.parse() API”, you’re saying “I want to transmit non-Json strings but claim they’re json “.
That breaks:
* old browsers - not supporting bigints would mean they couldn’t parse any of your “json” data, even if you weren’t using the bigints. Eg feature detection wouldn’t work.
* all shipped products that read json, because as with the browsers they could not parse any “json” that contained invalid data.
[edit:
Ok, let's try to do something about the endless downvotes:
Say you do JSON.parse("9007199254740994") - 2^53+2
Should this parse to a BigInt or a Number? In JavaScript today it will parse as a Number, without losing precision, but it is beyond the range of exactly representable integers in JS. You can see this by doing console.log(9007199254740995) and see that the output is 9007199254740996. So what happens if I do that following:
JSON.parse("[9007199254740992, 9007199254740993, 9007199254740994, 9007199254740995]")?
the first and third are exactly representable as a double, the second and forth are not. So should this parse as Number, BigInt, Number, BigInt? Or BigInt, BigInt, BigInt, BigInt? What value should be the trigger for treating an integer as a BigInt vs. a Number? What if we're doing
JSON.parse("[9007199254740992, 9007199254740993, 9007199254740994, 9007199254740995]").map(x=>x+2)
If any of the values get interpreted as a BigInt this will throw. But in existing browsers it won't.
]