More lenient JSON parser or seamless JSON5 integration

[qwwdfsad]

We have a steady stream of reports that all is about more permissive parsing:

• Trailing commas (#1812)
• Commas and comments
• Multiline strings
• Optional commas
• Optional quotation

The requirements altogether resemble JSON5 format (requested as #797), and we already have semi ad-hoc lenient mode that is an ad-hoc solution to JSON5.

We should decide whether we want to support a separate JSON5 format, gradually transform lenient mode into JSON5 or introduce json5Mode into our default Json format (that also can have a default object Json5) counterpart.

This issue is rather an umbrella for gathering feedback, so if you have any specific requests, whether they are covered by JSON5 or you would like them to be part of lenient parser, please let us know

[aSemy]

Supporting JSON5 would be great! It's a much nicer format than JSON, and I think it's quite fitting for Kotlin: comparing JSON5 to JSON is like comparing Kotlin to Java.

Here are some notes I have, after having worked with JSON5 in https://github.com/adamko-dev/json5-kotlin and https://github.com/xn32/json5k

Remove JSON?

What about removing JSON completely? JSON5 is a superset of JSON. If KxS implemented JSON5, then this would be supplant JSON, and JSON could be supported by setting the correct configuration for JSON5 encoding/decoding.

Even if JSON isn't removed, then JSON5 and JSON both have the same primitive/array/object types. Would it be possible to share the JsonElement classes (similar to the proposal in #1573?) Or would converter functions (fun JsonObject.toJson5Object(), fun Json5Array.toJsonArray() be possible/required?

Comments

Can KxS support comments?

I'd like to see an option to ignore them when encoding, or decoding. When decoding, decoding them as optional, additional properties #1978 might work?

See also:

• https://github.com/xn32/json5k/issues/6
• https://github.com/adamko-dev/json5-kotlin/issues/7
• #1970

[qwwdfsad]

Few more use-cases from Fleet:

• IDE is configured in JSON format (the most common one and easy to parse/highlight), but users leave comments on specific tweaks. For that, Jackson is used. The same goes for trailing commas
• Textmate bundles that are loadable by default in VS/Fleet/Sublime and also are rich on the commentary.
• Parsing dev containers

These issues are the last that require the Fleet team to use Jackson or look for hacky workarounds, it would be nice to address them in the next major API update.

Design-wise, it seems like we can either enrich Json configuration with flags one by one to introduce Json5 : Json(Json5Conf) later, or to introduce a standalone (and maybe a bit too lenient?) Json5 subtype/class with full-blown support

[sandwwraith]

After some consideration and study of use cases, we came to the conclusion that most of the usages of Json5 are related to parsing configuration or similar data. Such files mostly require two or three features: trailing commas, commentaries, and (sometimes) unquoted keys; while the rest of Json5 features, such as hexadecimal numbers or additional whitespace character set, are almost never used. We already support trailing commas (#1812) and unquoted keys in lenient mode, so to close this ticket, we simply need to add support for the commentaries.