feat: Add support for the JSONC format

[twpayne]

Fixes #2825.

@felipecrs can you test this?

[felipecrs]

This is awesome, and I'll test it.

I'd just say that I suggested fromJsonc because this is the language identifier used by vscode itself as well:

[felipecrs]

GitHub Markdown itself as well ```jsonc:

{
  // comment and trailing comma
  "test": true,
}

[felipecrs]

Deno also accepts .jsonc as a configuration file format:

https://deno.land/[email protected]/getting_started/configuration_file

[halostatue]

I think that adding jsonc to the supported types/extensions (with a note that it is Visual Studio Code’s variant of JSONC) but leaving the function as fromJWCC and a note (to improve search-ability) that it will successfully parse VS Code’s JSONC is probably the right choice here, as JWCC is extremely specific about the limited extension that it does to JSON parsing.

[twpayne]

Thanks for the super-fast testing and feedback!

So we need two things:

1. The name of the format, for use in documentation, and an optional link to the specification, or at least a link to where users can find out more about the format. The template function should be named after this format, e.g. fromJwcc or fromJsonc (the ugly lowecased acronym is for consistently with minorminds/sprig's ugly lowercased acronyms (Replace github.com/masterminds/sprig template functions #2668)).
2. A list of file extensions that we read in this format. Zero or more of .jsonc, .jwcc, .hujson, and maybe others.

Obviously, as there is no official standard here, there is no right answer, only a least-bad answer. The argument "do what VSCode does" is a very strong one as this is what most developers use these days.

So, is the following reasonable?

1. We call the format JSONC.
2. We never link to a specification because there is none.
3. We use the extension .jsonc only.

Thoughts?

[felipecrs]

So, is the following reasonable?

1. We call the format JSONC.
2. We never link to a specification because there is none.
3. We use the extension .jsonc only.

Thoughts?

This is very reasonable to me, although, I believe it would be nice to mention somewhere in the docs which Go library is used to parse JSONC (which would be the closest thing to a reference for a specification IMO).

[felipecrs]

Actually I tested it only now, but it is working great:

❯ printf "%s\n" "{" "  // This is a comment" '  "a": "whatever",' "}" | /mnt/c/Users/felip/Downloads/chezmoi-linux-amd64/chezmoi execute-template --with-stdin '{{ fromJson .chezmoi.stdin | toPrettyJson }}'
null
❯ printf "%s\n" "{" "  // This is a comment" '  "a": "whatever",' "}" | /mnt/c/Users/felip/Downloads/chezmoi-linux-amd64/chezmoi execute-template --with-stdin '{{ fromJwcc .chezmoi.stdin | toPrettyJson }}'
{
  "a": "whatever"
}

[felipecrs]

Do you think it's still worth supporting this hujson extension?

[twpayne]

Fair point, removed extension.

[twpayne]

I believe it would be nice to mention somewhere in the docs which Go library is used to parse JSONC

Good point. I added a link in the fromJsonc doc.

[felipecrs]

This is awesome, as everything about chezmoi.