I'm not sure what the the author would suggest but I'm increasingly of the opinion that config files formats should be treated as a compile target not a file that you edit.
There are formats that are easier to edit than others and formats that are easier to parse than others. But sooner or later all of them end up being created by an ill-suited template engine or embedding a programming language in the syntax (cloudformation, ansible, hcl2).
Why not treat the config file as a generated artifact that is readable but not written by a human. Tools like jsonnet (https://jsonnet.org/), dhall-lang (https://dhall-lang.org/), or my personal side project ucg (https://ucg.marzhillstudios.com/) allow you reuse values and safely generate your configuration formats with comments and logic all while bypassing the pitfalls of most formats.
They give you a purpose built language for creating configurations with comments and logic w/o putting that burden on your application later. And it allows you to ignore the parts of a particular format that cause you problems.
Create a good config file format and transpile that to a bad config file format for use in an application? I dunno I would rather just have the application use a decent config file format in the first place.
It's just a config file, no need to overthink this with translation layers IMO.
No good config file format will allow you to share common shared values across all of the formats. That database host everything uses? You'll have to copy paste it everywhere or use a template engine to generate all of the formats.
If you only have one application then it's overkill. When you have 10's of applications it's a life saver.
Good point. However hopefully whatever brilliant file format the source of truth is in will eventually end up being able to be consumed natively by the other applications and we can forgo the translation layer. Until then yes you have a good use case there.
> I'm increasingly of the opinion that config files formats should be treated as a compile target not a file that you edit.
I think this makes sense as far as it goes.
The first choice, no matter what the config file format, should be editing within a tool. The tool can check values, be accessible, assist in coordination, etc.
However, I think it's essential that the intermediate format be human readable and have the ability to contain comments. Because if something in the toolchain goes wrong, determining what the settings are right now on a particular system will be very useful. Being able to modify those settings by hand, though not your first choice, may save time and money and (depending on the system) lives.
Also, if the tool breaks, you can still change configs (though obviously this is not what you want).
Essentially, you should have a tool that edits config values with full explanations of their purpose. That tool should output a machine-readable format (JSON5, YAML, TOML) that supports comments with each value preceded with the comments containing their explanations and, ideally, a list of comments made when changing config values with previous values listed.
There are formats that are easier to edit than others and formats that are easier to parse than others. But sooner or later all of them end up being created by an ill-suited template engine or embedding a programming language in the syntax (cloudformation, ansible, hcl2).
Why not treat the config file as a generated artifact that is readable but not written by a human. Tools like jsonnet (https://jsonnet.org/), dhall-lang (https://dhall-lang.org/), or my personal side project ucg (https://ucg.marzhillstudios.com/) allow you reuse values and safely generate your configuration formats with comments and logic all while bypassing the pitfalls of most formats.
They give you a purpose built language for creating configurations with comments and logic w/o putting that burden on your application later. And it allows you to ignore the parts of a particular format that cause you problems.