TOML is a better format for configuration files IMO, if not for many reasons, primarily because TOML accepts comments.
However, one annoying thing for TOML was the lack of schema, and the reliance on JSON Schema for that. Which I decided to tackle years ago when I started the TOML Schema project. In the past few months I leveraged code agents to take to the finish line and got something compelling: tomlschema.org
Interesting. The website says that it's "validation-focused". I don't know how that plays out for TOML, but the lack of focus in json schema to define an interface in addition to validation can be very frustrating. Most of the time I would rather trade off some expressitivity in terms of validation in favor of having a defined typed interface into the validated data.
I'd argue that for code, yes, JSON is vastly closer to computer structures.
I think this is the real "why do so many tools have JSON config files": because it's just a literal notation, for basic data structures, that looks a lot like what many programming languages natively do, what their data structures natively are. The answer to the post is: it's mechanistic sympathy.
For humans, I do find TOML to be a lot easier to manage. Even if you have a really good editor that takes care of all the quoting/nesting/comma concerns for you, even if you have jsonc or json5 with comments, it's still not as easy/friendly as a big flat file with sections in it.
I find the toml structure impossible to follow as a human. It's like a complicated nested ini file. Asinine and terrible. I don't need a fancy editor (and I don't have one) to close my quotes and brackets. jq checks the syntax easily. On the other hand I have to crash my services to find out I nested shit wrong in toml because there's no structure
What are your thoughts on ini? My perspective is that >9/10 toml's are just ini files, straight up. The nesting seems rare, and rarely confusing to me.
I obviously disagree about the ease of json editing. jq tells me errors, sure. But formats where we don't need bespoke tooling, where notepad.exe work fine, are I think probably what config files should be more like.
My only experience with toml is complicated nested ones because I'm sure that the maintainers outgrew whatever was simple. Off the top my head it's just containerd config. Yaml probably a better choice than json and ini is fine if it gets the job done, but it's it really more than .env? My opinion is the env should do a lot of lifting anyway. I'm thinking there's always "tooling." My toml might syntax but be logically incorrect all the formats have that problem and linting doesn't stop at json. Like changing my containerd config I don't really know if it took or not
Comments
TOML is a better format for configuration files IMO, if not for many reasons, primarily because TOML accepts comments.
However, one annoying thing for TOML was the lack of schema, and the reliance on JSON Schema for that. Which I decided to tackle years ago when I started the TOML Schema project. In the past few months I leveraged code agents to take to the finish line and got something compelling: tomlschema.org
Interesting. The website says that it's "validation-focused". I don't know how that plays out for TOML, but the lack of focus in json schema to define an interface in addition to validation can be very frustrating. Most of the time I would rather trade off some expressitivity in terms of validation in favor of having a defined typed interface into the validated data.
Reading and writing json is so much easier than reading or writing toml imo
I'd argue that for code, yes, JSON is vastly closer to computer structures.
I think this is the real "why do so many tools have JSON config files": because it's just a literal notation, for basic data structures, that looks a lot like what many programming languages natively do, what their data structures natively are. The answer to the post is: it's mechanistic sympathy.
For humans, I do find TOML to be a lot easier to manage. Even if you have a really good editor that takes care of all the quoting/nesting/comma concerns for you, even if you have jsonc or json5 with comments, it's still not as easy/friendly as a big flat file with sections in it.
I find the toml structure impossible to follow as a human. It's like a complicated nested ini file. Asinine and terrible. I don't need a fancy editor (and I don't have one) to close my quotes and brackets. jq checks the syntax easily. On the other hand I have to crash my services to find out I nested shit wrong in toml because there's no structure
What are your thoughts on ini? My perspective is that >9/10 toml's are just ini files, straight up. The nesting seems rare, and rarely confusing to me.
I obviously disagree about the ease of json editing. jq tells me errors, sure. But formats where we don't need bespoke tooling, where notepad.exe work fine, are I think probably what config files should be more like.
My only experience with toml is complicated nested ones because I'm sure that the maintainers outgrew whatever was simple. Off the top my head it's just containerd config. Yaml probably a better choice than json and ini is fine if it gets the job done, but it's it really more than .env? My opinion is the env should do a lot of lifting anyway. I'm thinking there's always "tooling." My toml might syntax but be logically incorrect all the formats have that problem and linting doesn't stop at json. Like changing my containerd config I don't really know if it took or not
TOML is quite ridiculous. There are always an infinity of ways one can write the same values.
It should really define sections as something different from dot-separated identifier groups.
I find TOML is nowhere near as good as YAML. I'd even rather use jsonc.
Yeah, I just use JSON5, it solves all the issues with normal json