The 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 :)
Re:JSON5 – JSON for Humans
by AdieuToLogic on Monday December 09, 2024 @07:57PM
(#42372459)
All 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.
Using a YAML parser to parse JSON+comments is like bringing a tank to a knife fight... If you only parse "trusted" input, i.e. you can guarantee that no one is ever going to pass anything but JSON+comments, and you don't do it in any high-TPS scenarios it's probably fine to use a YAML parser
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?