This was intentional because tools like VSCode support trailing commas even in JSON files (no parsing errors). Eventually, users got used to this weird behaviour without even noticing.

To try to support these use cases, we let the user decide what they want by providing highly customisable options.

I don't mind changing this, but it would break a lot of use cases, and users won't be able to support them

Why not follow prettier's convention? It correctly formats both JSONC and JSON based on extension, not even a config file is needed.

Also, if biome knows tool specific config formats, then it should definitely recognize package.json files. I guess the package.json breaking is definitely a bug.

As I said, I don't mind changing this, but what about those uses cases where users want trailing commas in JSON files? That's the point of discussion.

Anyway, in my opinion supporting JSONC-in-JSON breaks the whole ecosystem of JSON parsing tools, it's a super dangerous thing to do for a linter. If VSCode users want commas, they should rename their files.

One solution could be:

1. Same defaults as prettier => add trailing comma to JSONC without any config.
2. Two ideas:

• Add config option like json.formatter.jsoncInJson
• Introduce separte json and jsonc formatter config.

Some JSONC parsers don't support trailing commas. If I remember correctly the VSCode team recommends to not adding trailing comma in its JSON files recognized as JSONC files.

IN that case this could make json.formatter.trailingCommas pretty useless if we don't add trailing commas in JSON and JSONC files.
The proper action seems to use overrides with json.formatter.trailingCommas.

A related issue I've just run into is that tsconfig.*.json is also not recognised correctly.
#4769

Prettier also gets this one perfectly.

Basically prettier really gets JSON/JSONC formatting, without any config it just works. Both on comments in JSON, both on commas in JSONC, etc. Please take it as a reference implementation for JSON formatting and follow their defaults.

Both on comments in JSON

This is debatable, and maybe a personal preference. Comments in JSON aren't allowed. Agree to disagree, but we prefer to follow the spec by default.

Up there you stated: "This was intentional because tools like VSCode support trailing commas even in JSON files (no parsing errors). Eventually, users got used to this weird behaviour without even noticing."

I cannot follow the logic here.

Apologies for the misunderstanding. In that comment I explained the reason why the option exists and why it behaves like that. However, we agreed that there's a bug to fix :)

OK, if the tools specific configs work correctly, then it's a great first step.

For general files, I also believe that normal JSON should be according to the spec, so no trailing comma, no comment.

For JSONC I have no idea, it's not really a format. C can mean comma and it can also mean comment, it's depending on the tool being used.

Adding the Biome 2.0 label, since I think it would be the moment to fix this if we can. Agreed it needs more careful discussion though.

Introduce separte json and jsonc formatter config.

I’m inclined to lean in this direction, but it’s still tricky. We could have a dedicated jsonc.formatter.trailingCommas option in addition to json.formatter.trailingCommas, where the default for the former is the value of the latter. But that suggestion may complicate things for our overrides behavior.

What do you think?

I recommend the following rule for JSON files:

• JSON files should always be according to the spec, no trailing commas, no comments. The only exception is the magic list of config files. There should be no config option for JSON files, otherwise it'd brake the specs.

And for JSONC files:

• JSONC files should have the trailing commas user-configurable. Ideally it'd be called jsonc.formatter.trailingCommas and not json.formatter...

Yes, I think that may be the way to go indeed.

It does take away the ability for users to override the behavior on regular JSON files, but that may not be much of an issue. In another thread we also discussed the ability to override the file type of specific files and/or extensions. So someone who really wants could always force the behavior of JSONC on JSON files anyway.