Completely agreed. For me, writing YAML always feels like a guessing game.
When I first encountered an ESLint config written in YAML, for example, it took me like a dozen tries (no exaggeration) to successfully convert a
[2, "always"]
type value into a more advanced
[2, { "options": blah, "foo": bar }]
value. The ways that intuitively seemed like they definitely should have worked, didn't work, and I consider myself a competent programmer.
I came to dislike it even more once I found out it had features like &anchors, <<:, etc. Not only do I find the syntax repulsive, but having custom user-named sections whose identifiers aren't actually significant and don't end up in the parsed structure is probably wasting a ton of people's time as they Google documentation for config section names that the consuming program doesn't actually understand because they don't really exist (they were just named at the author's whimsy).
When I first encountered an ESLint config written in YAML, for example, it took me like a dozen tries (no exaggeration) to successfully convert a
type value into a more advanced value. The ways that intuitively seemed like they definitely should have worked, didn't work, and I consider myself a competent programmer.I came to dislike it even more once I found out it had features like &anchors, <<:, etc. Not only do I find the syntax repulsive, but having custom user-named sections whose identifiers aren't actually significant and don't end up in the parsed structure is probably wasting a ton of people's time as they Google documentation for config section names that the consuming program doesn't actually understand because they don't really exist (they were just named at the author's whimsy).
It's not worth it. Use JSON, or possibly JSON5.