Also, if the CD process is not too dumb the json validate will find the errors before the file enter production which will save you. At my first company they rewrote our ansible inventory files in json because a yaml uncaught indentation mistake made a firewall open by default, silently.
good:
- a
- b
- c
bad:
- a
- b
- c
Obviously when I show you this, it's clear that b is incorrectly indented, but in a real file, this can be a nightmare to figure out. Particularly if the entries are nested, or tab characters are involved.Meanwhile, the error in JSON is way more obvious:
{
"good": [
"a",
"b",
"c"
],
"bad": [
"a - b",
"c"
]
}No... 'cause it really depends your data and use case. For me, it's as clear as
"bad": [
"a":[
"b"
],
"c"
]
}But here is the issue: the errors caught in a json-validate won't be in a yaml-validate. If you have 15 inventory file to write per day, you will do a lot of copy pasta, sometimes with errors, and most of those times ansible won't resolve because the yaml was obviously false. The one time it wasn't, it was sadly on a critical part of our infra, and almost cost us a client (and definitely costed trust).
Yaml is way more permissive (because it has more capabilities). But we didn't care about map and semi-code or whatnot. If you need it, more power to you, it just wasn't our original usecase. So they wrote some perl json->yaml interpreter with restricted keywords, and after that, the misalignment risk was negated. Ultimately i arrived at the company, was told the story, then wrote stuff to convert excel->json, then SQL->json, and effectively in the end the extra conversion was unnecessary, and probably harder than just converting directly in yaml. I'm not saying yaml is worse than json, i think in 80% of cases, it's better. I'm just saying that in the rare cases where being correct is way more important than being fast, i'd use json.