[munificent]

> The distinguishing draw of yaml is largely the "easiness" of not having explicit opening or - more importantly - closing delimeters.

Along with a coworker, I wrote the package manager for Dart, which uses YAML for its main manifest file (pubspec.yaml). The lack of delimiters is kind of nice but wasn't instrumental in the choice to use YAML.

It's because JSON doesn't have comments.

If there was a JSON+comments what was specified and widely compatible, we would have used that. YAML really is a brittle nightmare, and the lack of delimiters cause problems as often as they solve them. We wrote a YAML parser from scratch and I still get the indentation on lists wrong sometimes.

But YAML lets you actually, you know, comment out a line of text in it temporarily, and that's really fucking handy. I think of Crockford had left comments in JSON, YAML would be dead.

[rendaw]

JSONC is JSON with comments (and trailing commas) and it's fairly widely supported, namely because VS Code ships with support built in and they use it for all their config files. I've seen libraries for a number of languages.

VS code defaults to complaining about trailing commas though (the warnings can be turned off though (it feels like a hack and they didn't properly document it though (it is an officially sanctioned procedure though))).

[lucideer]

> It's because JSON doesn't have comments.

This is a big plus but JSON5 has pretty widespread language library support - probably equal to that of YAML tbh (e.g. Swift has native JSON5 support, I don't know that anyone natively supports YAML). Any reason not to opt for it here?

[munificent]

I believe JSON5 didn't exist when we first wrote pub. If it did, it certainly wasn't widely known.

Obviously, migrating to it now when there are thousands and thousands of packages and dozens of tools all reading pubspecs would be much more trouble than it's worth.

[lucideer]

Understandable. I just checked & JSON5 was just 1 year later but even then it would've taken a lot longer to gain sufficient traction to be well supported.

[Diti]

Most protocols defined in RFCs require the use of regular JSON. You don’t have a choice.

[lucideer]

Not sure what context you're referring to but we're discussing configuration file formats, not data transports, so I doubt that would be a frequent issue.