Trailing commas

[Timmmm]

The original JSONC supports trailing commas. Is it really a good idea to make another format with the exact same name that doesn't support trailing commas?

[Timmmm]

Also I checked all the implementations you link to and they mostly support trailing commas (sometimes configurably).

[Timmmm]

And actually you're not even the first to reuse the JSONC name for something else - this parser that you link to is called jsonc but actually parses a totally different format.

[DecimalTurn]

The original JSONC supports trailing commas

The page you are linking to talks about the JSONC mode, it is not a standard. Furthermore, the wording is ambiguous:

[...] the mode also accepts trailing commas, but they are discouraged and the editor will display a warning.

A standard can't afford such ambiguity without being called out (see #5). A standard can be seen as a collection of suggestions that should be followed for maximal compatibility, in that context what would it mean to say something is "accepted", but "discouraged"? If it's discouraged, the suggestion is not to use trailing commas, so a standard based on that word should exclude trailing commas from the spec. If you put more importance on the "accepted", then yes, you could say that it should be part of the spec, but again, the whole sentence is ambiguous if you try to make a standard out of it. The current version of the jsonc.org standard had to be clear about what it recommends in a non-ambiguous way.

For that reason, the spec is based on the default behavior of the node-jsonc-parser, which is what VS Code uses under the hood.

Also I checked all the implementations you link to and they mostly support trailing commas (sometimes configurably).

I was actually thinking of making this information available in the listing, probably in the form of a table. If you want to share your findings, please do and this could definitely way in favor of including trailing commas in future versions of the spec.

And actually you're not even the first to reuse the JSONC name for something else - this parser that you link to is called jsonc but actually parses a totally different format.

I don't see how it's something else, can you elaborate?

[Timmmm]

The page you are linking to talks about the JSONC mode, it is not a standard.

It is a de facto standard created by Microsoft for VSCode. The node-jsonc-parser you linked to was written by Microsoft for use in VSCode.

A standard can't afford such ambiguity without being called out

Standards can recommend or discourage things without banning or mandating them. That's why RFC2119 has SHOULD, SHOULD NOT and MAY - not just MUST and MUST NOT. Recommendations are very common in standards.

By the way it's worth noting that trailing commas weren't always "discouraged". I'm not actually sure why they changed it. I tracked down the original commit that made them into warnings (which is why they later added the "discouraged" text), but the commit message is not very helpful. I might make an issue because I can't see any reason to have a warning for them. It's already not JSON-compatible.

If you want to share your findings

Sure:

Parser	Trailing commas?	Comments?	Notes
node-jsonc-parser	Configurable (default: no)	Configurable (default: yes)
Glaze	No	Configurable (default: no)
massivefermion/jsonc	Yes	Yes	Totally different "JSONC"
tidwall/jsonc	Yes	Yes
NickolaiBeloguzov/jsonc-parser	No	Yes	Naive regex based; allows comments in strings
dprint/jsonc-parser	Configurable (default: yes)	Configurable (default: yes)
JSON for modern C++	Configurable (default: no)	Configurable (default: no

I don't see how it's something else, can you elaborate?

It allows unquoted keys and string values, multline strings, etc. It's very different.

[DecimalTurn]

It is a de facto standard created by Microsoft for VSCode.

It's hard for me to see it as a standard when even the VS Code team claims it's not a standard. I get that it can be seen as a de facto standard against their will, but that seems like a recipe for more confusion. Personally, I wish the VS Code team/node-jsonc-parser team would assume the responsibility of making a clear standard, I would even give them the jsonc.org domain if they asked me nicely.

Standards can recommend or discourage things without banning or mandating them

I know they can, it just seems that they can't without being called out in this context. The ambiguity around trailing commas seems to really be a problem that is causing confusion in the JS/TS ecosystem.

commas weren't always "discouraged".

This information and the likely motivation for the change is already mentioned on this page: https://jsonc.org/trailingcommas

The “JSON with Comments” mode in VS Code used to allow trailing commas without any warnings by default, but this was eventually changed to discourage their use and promote better compatibility with other JSONC parsers (source).

And thanks a lot for the detailed table. I'm thinking a table like this should be part the webpage as well. If you'd like to make a PR for this, I'd happily review and merge it, but if you prefer I can use it and add a mention somewhere without making you a contributor the project.

[DecimalTurn]

Regarding massivefermion/jsonc, it does indeed extend beyond what is JSONC, but since it can at least parse JSONC, it would be beneficial to keep it on the list until there is another parser available for Elixir.

[Timmmm]

Personally, I wish the VS Code team/node-jsonc-parser team would assume the responsibility of making a clear standard, I would even give them the jsonc.org domain if they asked me nicely.

I agree, that would be the best outcome.

https://jsonc.org/trailingcommas

Ah that is a good page. I wonder if the best thing would be to make "are trailing commas supported" part of the name. JSONC for JSON with Comments, and JSONCC for JSON with Comments and trailing Commas.

If VSCode adopted this, and had both JSONC and JSONCC modes, and if json.org used that naming system, then I think it would fully solve the confusion.

VSCode could hardcode tsconfig.json as JSONC, but vscode/config.json as JSONCC. Then there would be no warnings or "discourage"; only accurate errors.

We would need to get VSCode on board with it though.

[DecimalTurn]

The following PR should address this issue: #14

It would put the spec more in-line with what is the current position of the VS Code Team and it's closer to what was the original text from a few versions ago. Feedback is welcome.

[Timmmm]

We would need to get VSCode on board with it though.

Btw I did ask them about this but they're unfortunately still very "JSONC is only an internal format only for us and nobody else should use it" :-/