The yaml document from hell[1] needed three changes ("*.html", "*.png", "!.git") to be parsed by yq at all. "Norway problem" is not a problem as no was converted to a quoted string. Unquoted strings in "allow_postgres_versions" part were not quoted by yq.
It's a bit hard to be sure because YAML is so insane, but I would argue that yq's behaviour is not incorrect?
It is erroring on `*.html`, which is reasonable because `.html` is an invalid anchor identifier, though the error is not that useful. The parsing of the unquoted version numbers also seems to be "correct", in that things that look like numbers are supposed to be parsed as numbers.
Templating yaml with a text templating language like Helm's templating language is a terrible idea. Templating objects and serializing them to Yaml (with input also being Yaml) I find quite nice: https://github.com/con2/emrichen
1. yq appears to accept the unquoted tag !.git for me, without change? (This is at least a correct parse syntactically, I think.)
2. The unquoted aliases (*.html, *.png) are invalid: that yq errors on them is the correct output. (I.e., if you want those as literal strings, they MUST be quoted.)
"The plain (unquoted) style has no identifying indicators and provides no form of escaping. It is therefore the most readable, most limited and most context sensitive style."
Which reads to me that they expected people to treat the plain style as a convenience that had notable downsides.
Edit: Note that this is the "plain" style, where there's also single and double quoted styles.
A reasonable choice (in contrast to "no" or "null"). YAML is simply not a format for all use cases. It's good enough for many tasks, and more readable than most other formats where it fits.
Maybe, but unquoted strings not being the right choice for all use cases (or, similarly, structure-by-indentation not being) doesn’t show that, since YAML supports unquoted and quoted strings, and supports both indent-sensitive “block style” and delimiter-based “flow style”.
To me, it doesn't fit where people with a less technical background can/must edit configuration files, or where there's a large risk of mixing up null and "null". For readability, it's fine, except for the ugly node reference syntax.
[1] https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr...