New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow JSON with trailing commas #5708

Open
szhu opened this Issue Jan 3, 2019 · 13 comments

Comments

Projects
None yet
6 participants
@szhu
Copy link

szhu commented Jan 3, 2019

I'm looking for a way to support the following style:

  • JSON-based
  • Always quote keys
  • Always include trailing commas

This would typically be not a problem -- I should be able to set parser: json and trailingComma: all. However, #2308* disables this specific combination and I can't get around it.

Here's my use case: I want Prettier to format my VSCode settings files, which I keep in a git repo.

  • VSCode requires keys to be quoted, so I can't use the json5 parser.
  • I would like trailing commas to make diffs more readable.

Note: I originally filed this bug in another repo prettier/prettier-vscode#589

* I am aware that #2308 was created because trailing commas broke VSCode. However, times have changed and VSCode settings files now support trailing commas.

Thanks!

Prettier 1.15.3
Playground link

--parser json
--trailing-comma all

Input:

{
  //
  "a": 1,
  "b": 2,
}

Output:

{
  //
  "a": 1,
  "b": 2
}

Expected behavior:
I'd like a set of input options that doesn't make changes to the input; i.e., I want the output to also be

{
  //
  "a": 1,
  "b": 2,
}
@lydell

This comment has been minimized.

Copy link
Collaborator

lydell commented Jan 3, 2019

--parser json-vscode :shudder:

@j-f1

This comment has been minimized.

Copy link
Member

j-f1 commented Jan 3, 2019

wow, they made their own JSON parser in the first commit, and still use it.

@szhu

This comment has been minimized.

Copy link

szhu commented Jan 3, 2019

@lydell the problem isn't the prettier json parser, it parses trailing commas just fine. The problem is that there is an explicit override to disable trailingComma when the parser is set to json. Can we somehow make that exception a little more nuanced, or give a way to override that override?

Also, this particular syntax isn't VSCode-specific, it's a pretty common JSON superset that's used in config files. Sublime Text's config files accept comments and trailing commas as well.

@bakkot

This comment has been minimized.

Copy link
Collaborator

bakkot commented Jan 9, 2019

Have you considered suggesting to vscode (and whoever else) that they adopt JSON5 for their config, rather than this other intermediate thing? I don't think it would be a breaking change.

@bakkot

This comment has been minimized.

Copy link
Collaborator

bakkot commented Jan 9, 2019

See also #4639 (linked from the prettier-vscode issue).

@ikatyang

This comment has been minimized.

Copy link
Member

ikatyang commented Jan 9, 2019

Personally, I think jsonc (the language named JSON with Comments in VSCode, which is also used by TypeScript tsconfig.json) is better than JSON5 since it only adds missing features that are necessary so it's relatively simple.

I was thinking of adding a --parser jsonc to address this issue, but then I found that its name (JSON with Comments) is very confusing since it looks like JSON + comments but it's actually JSON + comments + trailing commas while our --parser json already handles JSON + comments, so the jsonc description may look something like "JSON with Comments: same parser as json, but trailing commas are allowed", which is super confusing.

@bakkot

This comment has been minimized.

Copy link
Collaborator

bakkot commented Jan 9, 2019

Since jsonc is a subset of JSON5, perhaps the json5 parser could consume JSON5 and emit jsonc? I think that's pretty much just a matter of accepting #4639, though there might be other differences in output which I'm missing.

@szhu

This comment has been minimized.

Copy link

szhu commented Jan 9, 2019

Personally, I think jsonc (the language named JSON with Comments in VSCode, which is also used by TypeScript tsconfig.json) is better than JSON5 since it only adds missing features that are necessary so it's relatively simple.

@ikatyang yeah I think json5 is a little too over-the-top, at that point they might as well be using yaml…

@ikatyang

This comment has been minimized.

Copy link
Member

ikatyang commented Jan 9, 2019

Since jsonc is a subset of JSON5, perhaps the json5 parser could consume JSON5 and emit jsonc?

We did not have --printer <something> at this point so we can only use --parser jsonc to hint printer to output jsonc, and all of our JSON-like languages use the same parser (parseExpression from @babel/parser) so it's actually something like --parser js-expression --printer some-json-variant.

I think that's pretty much just a matter of accepting #4639

They are the same in theory, but accepting #4639 does not look like the same to me since we don't want to add more options (same as respecting original text).

@szhu

This comment has been minimized.

Copy link

szhu commented Jan 9, 2019

I am suspecting that the most seamless solution might not be to change the parser property, but to change the trailingComma property, since it already does something similar. Maybe have trailingComma: es5 not include it in JSON but have trailingComma: all include it?

Some other suggestions:

  • Add a compatibility property: compatibility: ["strict-json", "es5"]
  • Add a way to override by parser, not just by syntax. Then tell everyone who uses strict json to add overrides: {parsers: "json", options: {"trailingCommas": false}}
@bakkot

This comment has been minimized.

Copy link
Collaborator

bakkot commented Jan 9, 2019

#4639 wouldn't require a new option, would it? It could just always output anything parsed as --parser=json5 as valid jsonc, where possible.

@szhu

This comment has been minimized.

Copy link

szhu commented Jan 11, 2019

True, but would it be possible for future changes to json5 output to be non-jsonc-compatible?

@duailibe

This comment has been minimized.

Copy link
Member

duailibe commented Jan 14, 2019

It's hard to predict what changes could "break" the output but I think it's safe to assume that if the source is jsonc-compatible, the output would be too.

For example, let's imagine the multiline feature didn't exist in JSON5 and the feature was just added

The following would continue to be JSONC-compatible:

{
  "foo": "bar\nbaz",
}

But if you change your source code to use this new feature, then it woud no longer be compatible:

{
  "foo": "bar\
baz",
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment