Support JS-style comments in JSON

Apologies if this isn't the right place - it's not, feel free to redirect me to where the right place is.

I propose we extend JSON with comments using JS's grammar:

  • Single-line comments start with // and end with line terminator sequences (CR, LF, LS, or PS).
  • Multi-line comments start with /* and end with */.
  • Implementations should (not "must") treat this as equivalent to whitespace.

Despite the extremely performance-sensitive nature of JSON parsers, I don't anticipate this to cause performance problems to existing parsers.

I don't really need to state the demand here (just search "json with comments" and it'll show up within the first page), and many things (ranging from ESLint and npm to Visual Studio and even Chrome in a few places) support it already. .NET has native support for it (off by default) in its built-in JSON parser. There's also many spec extensions providing just that. I feel at this point it's time to place it in the language proper, RFC update and all. If anything, it's already starting to result in a partial ecosystem fork (.NET's standard library and the increasing use of JSON5 in place of native JSON are evidence of this), and that's not exactly a good thing for interoperability.

There are sooo many JSON parsers out there (many legacy ones that aren't supported anymore too), I doubt we can just update the JSON standard the same way we can do with EcmaScript. The only safe way I can think of to update the standard would be to make a separate standard for it, call it something else, and have everyone get on board with it. This unfortunately seems to be what many groups of people have already tried to do independent of each other, and we're really struggling with the whole "get everyone on board with a single new standard" thing. I guess it could help if whoever's in charge of the JSON standard came out with their own standard, or pointed to an existing standard and declared it as the next version. But, the "next" version would need to have a different name from just JSON, so old JSON parsers can still be considered valid.

As the previous comment says, JSON can never be updated without breaking a great many consumers, which we are not inclined to do. We could in principle add a new JSON5.parse or whatever, but it seems premature to do that at this point in time.

I guess it could help if whoever's in charge of the JSON standard came out with their own standard

That's also TC39.

How exactly would making what's currently invalid syntax valid potentially breaking?

Of course, legacy, unmaintained parsers won't be updated, but consider that we were able to add two previously invalid characters to the list of valid string characters. I don't see why that would be possible and this wouldn't.

In this case, it's slightly larger, but it still won't impact the semantics of JSON for most uses. (For the few it would, they're probably already using this proposed extension.)

Would love to be able to use comments inside JSON too, although I understand it is complicated.

Actually I think that it would not be such a breaking change. Most of the old / deprecated JSON parsers will still be using the same deprecated JSON files they were used to use, and in most places the new JSON standard is used, the parser used will be updated accordingly.
The case where an old parser is used but new JSON files are provided somehow should be quite rare, and if that ever happen, that also means that the project is probably still maintained (and so there are good chances that the parsers will be updated too).

Also, if at some point we do decide to update the current JSON standard, I propose to take this opportunity to also add support for trailing commas, because this would also be an easy fix for such a pain.

I would love to have comments and trailing commas in JSON as well. I'm not sure what the performance implications of all of this are for parsers, I doubt there would be any issues, but if there are, I would rather JSON tailors more to the "readable-data-transfer" idea, and less to the "config file" idea it was never meant to be used for.

As much as I hate to admit it, I also think there's value in having a JSON format that does not support comments - it provides some nice guarantees. For example, maybe you're on a server, with a config folder full of json config files. You might think you could add comments to these files, but if the server ever writes to any of these files, it'll blow away your comments. If some of the files were named .json5 for example, then it would be easier to know which files can have comments and which ones can't.

...I guess this isn't a very strong argument, but it's a little something to consider.

I don't think it's possible or sensible to change the JSON standard, but one could make JSON5 an internet standard and provide native support for it in JavaScript - in addition to, not as a replacement of, JSON.

1 Like