.yaml, .toml, etc?
I usually use Json5. It's JSON, but with all the weird quirks fixed (comments added, you can use hex numbers, you can have trailing commas etc.)
Oh that's interesting. Wonder how many libraries out there support it...
I don't know if it's actual json5, but eslint and some other libraries use extended, commentable json in their config files.
A lot of good answers but I would add one note:
- use a format that supports comments, and JSON is not one of those...
I liked the idea to be honest. I can just call the entry "description" instead and all is good ^^
I believe the JSON deserializer .NET ships with has options to allow C#-style comments in JSON files.
json with comments can be parsed by a yaml parser. It's how I write yaml, in fact (yaml is a superset of json. any valid json is valid yaml, but it also supports comments)
It depends what you need your configuration file to be:
Need a well defined easy to understand concrete configuration file?
- Use
.toml
. It was made to be both human and computer friendly while taking special attention to avoid the pitfalls commonly found in other configuration files by explicitly stating expected types around commonly confused areas.
Need a simple to implement configuration file?
- Use
.json
. It's famous for being so simple it'screator"discoverer" could define it on a business card.
Need an abstract configuration file for more complicated setups?
- Use
.ncl
. Nickle allows you to define functions so that you can generate/compute the correct configuration by changing a few variables/flags.
- Use
Easily the format no one's heard of that you jammed together in your attic when you were twelve.
https://nestedtext.org/
It's like yaml but simple, consistent, untyped, and you never need to escape any characters, ever.
Types and validation aren't going to be great unless they're in the actual code anyway.
Depends on what you mean exactly with "file format".
If declarative functional programming falls under that, I think something like Nickel, the already mentioned Dhall or Nix. Though Nix more so for packaging and some kind of system management (NixOS?), it's not easily embeddable into a runtime (your app?). Nickel or Dhall is better for that, as they are built from ground up with that in mind, Nickel is maybe the successor of Nix as it is inspired by Dhall and Nix (one goal is to use Nickel as frontend).
The reason why I recommend a simple declarative language, is that they are IMHO much better composable as it lets the user hide boilerplate via functions. I almost always feel limited by static configuration formats like yaml, json etc..
No reason to go beyond simple key-value format like dotenv or just env variables. If you need more structure then maybe you are confusing configuration with state and this is not really the same thing.
XML would be great if it wasn't for the extended XML universe of namespaces and imports.
XML to transform XML to import into more XML? Can't we just have a config file that isn't setting up some big tie in?
Tyson is nice - esp. if you are already using TS/JS.
https://github.com/jetpack-io/tyson
It really depends. I usually prefer json. It's easily understandable from humans and from machines, it doesn't depends on indentation and above everything else I like it very much 🤣