I was expecting this to validate the configuration files are also valid for their use cases, not just valid JSON, TOML, etc.

If you're looking for that and Python is your jam, the library cerberus[0] is very good at it.

[0]: https://github.com/pyeve/cerberus

It doesn't include validators for TOML and INI, but if you're doing JSON and YAML, I would take a look at using or building upon CUE (https://cuelang.org/). It is a different take on schema definition (plus more), and is surprising terse and powerful model.

I’m one of the maintainers of the project. We’re a DevOps team and maintain a lot of different types of configuration files for all the different tools and services we support - often in the same repo. Rather than using a lot of different validators for each config format we wanted a single tool to validate all types. This enabled us to include config validation as a quality gate in our CI/CD to detect config file syntax issues early before they failed in functional testing. We open-sourced it to help other teams with similar workflows. Please let me know if you have any comments or suggestions!

I've been thinking about this a bunch. It's weird that we our apps are typesafe in lots of ways and then just hope that some magic string config & env vars are available, and there isn't even a comprehensive list of what our apps expect.

Anyone else think a property spec like the specker thing, than maybe some code gen on top of that that enforces the code is actually using it is interesting?

I recently made a python library that does this. You build up specs (a json/dict), and at each layer that descends, you add a `spec_chain` entry, and build another spec for the next level. Once the specs are built, you can validate, as well as get config defaults from it.

https://pypi.org/project/specker

For validating the actual values and types in config files, I've been planning to use JSON Schema to define the configuration data and then validate files against it. But I haven't seen others talk about that a lot - is it something I'm missing?

Anyone else have any suggestions for improvements or things that you'd expect to see in a tool like this? I'll take anything you've got :D All feedback so far has been added as Github issues.