3 ms·
> The only thing that JSON is really missing are comments and trailing commas. I use JSONC for that. YAML[0] supports JSON formatted resources and octothorpe (
by AdieuToLogic 2y ago
> The only thing that JSON is really missing are comments and trailing commas. I use JSONC for that.
YAML[0] supports JSON formatted resources and octothorpe ('#') comments as well. I didn't see anything in the spec specifically allowing for trailing commas however.
Here is an exemplar using the Ruby YAML module:
#!/usr/bin/ruby
require 'yaml'
puts YAML.load(
%/
# YAML is a strict superset of JSON, which
# means supporting octothorpe end-of-line
# comments is supported in JSON formatted
# YAML if and only if the content is multi-line
# formatted as well (like this example).
{
# This is valid YAML!
"foo" : "bar"
}
/
)
0 - https://yaml.org/spec/1.2.2/ https://yaml.org/spec/1.2.2/
- ratorx 2y agoWhilst YAML is an option, if the choice is between having the unnecessary extra features of JSON5 or YAML, JSON5 seems like the clear winner. Allowing multiple types of quotes may be an unnecessary feature but it is a clear lesser evil compared to the mountain of footguns that YAML brings with it.
- AdieuToLogic 2y agoHow does defining a YAML resource strictly in terms of well-formed JSON + octothorpe comments introduce "the mountain of footguns that YAML brings with it"?
- ratorx 2y agoIt doesn’t, quoting strings does solve almost all issues, but it does leave potential footguns for the future. If you don’t enforce it, in the future the “subset of YAML” property might get weaker, especially if someone else is modifying the config. If you treat config files the same as code, then using a safe subset of YAML is the same as using a safe subset of C. It is theoretically doable, but without extensive safeguards, someone will eventually slip up.
- nine_k 2y agoThe problem of yaml is that it allows too much. It allows unquoted strings, and those can be interpreted by the parser as numbers, timestamps, booleans, etc. This is a source of many fooguns. Use of indentation to denote nesting can sometimes be an anti-feature, too, because while using that the format does not provide a way to make certain that the entire stream has been read (parens balanced). This may lead to problems or even exploits. Pure JSON is so painful for human consumption though, I willingly choose yaml if it's the only alternative. JSON5 may indeed be a sweet spot between human-friendliness and lack of nasty surprises.
- AdieuToLogic 2y agoAs I mentioned in a reply to a peer comment, the problems you describe regarding YAML appear to be about the commonly used format most of us think of and the totality of the YAML feature set. What is illustrated above is the definition of a specification-compliant YAML resource strictly using JSON constructs + octothorpe end-of-line comments. Does this usage mitigate the concerns you have identified?
- nine_k 2y agoThe problem is that self-restraint only takes you so far. Typos exist. Human mistakes exist. Machine errors exist. Malicious inputs exist. A good parser does not just accept the inputs you find valid, but also rejects inputs you deem invalid. Running a linter that would report or amend all the footgun-wielding features of yaml before parsing is tanamount to running another parser. Then why bother :)
- AdieuToLogic 2y agoAll good points. My philosophy to address same is to employ test suites as a form of sanity checking for JSON/YAML/XML/et al configuration resources. Still, it would have been nice if YAML had reduced the surface area to verify in order to establish confidence in its content.
- milch 2y ago