I might sound like heretic but as someone who always keeps an eye out for configuration systems (I've tried edn, raw json, dhall, cue, hcl to name a couple) over the years, I'm sticking to jsonnet + jsonschema. Some reasons in favor of what might seem like an antiquated / type-poor system:
- jsonnet fixes almost all of the superficial complaints people have about json (no comments, invitations to inconsistent layouts, no composition, no functions)
- jsonnet has a very handy formatter and has trailing commas (simple diffs)
- jsonnet can import jsonnet as well as json so you can "refactor" your configs using code and/or plain data
- json is everywhere and nearly every language has a parser the standard libraries
- jsonnet is not turing complete; I consider this a huge plus as effectively you are always operating in "data space"; everything is a shape transform, nothing more, nothing less
- you can do further slicing and dicing with other mature tools like jq, jc, yq, gron, whatever
- your outputs being plain old json, leverage whatever json schema ecosystem tools you have
- json schema being old, you have lots of codegen tools available
- the jsonnet library has go, python, node, C++ bindings
- super easy to learn and run interactively
the biggest thing that's sorely lacking in this ecosystem are whatever jsonschema doesn't support in its spec for validation, like complex XOR relationships. Sometimes I wish these are declarable in data space, but on the other hand, configs with complex relationships like these often have business code backing them. Another weakness is if you have a large anthology of schemas/templates/source data you need to figure out a management method and hierarchy yourself.
Maybe pkl has a nice answer to these but J+J is really quite robust. I'd even go further and say it's beneficial to adopt a schema-first mindset and make it a habit to generate schemas. These tools are so lightweight and ubiquitous, it makes quick work for cranking out a schema and validating everything as you go.