When a project's config inherits yours
Two configs for one tool, the user's and the project's, and no rule anywhere about which one wins. Twenty minutes to make one a layer of the other and keep a straight answer about where every value came from.
Categories
5 pages
config
Layered configuration for Go, pulled out of go-tool-base so anything can use it. It reads your settings from files (in whatever format), the environment, flags and remote systems like Consul, and merges them with a precedence you can read off the call site. The part that sets it apart: it writes changes back without wrecking the file a person wrote, comments and all, and it can tell you exactly which source set any value. Around it sits a family of small adapter modules, one per format and one per backend, so you only carry the ones you actually use.
A format per module, not a fatter config core
Viper reads a dozen extensions. Mine reads one, and the other formats live somewhere else entirely. Here's what that bought, measured rather than asserted.
The writer I added, and the Viper I deleted by accident
I set out to add a config writer and keep Viper. I ended up keeping the writer and deleting Viper, and I didn't notice until it was already gone.
Layering config without losing where a value came from
Four places a config value can come from, and the only question that matters at the wrong end of an incident: which one won, and why. Twenty minutes, one module, no services.
Everyone reads your config. This one writes it back.
A configuration module that writes changes back without wrecking the file a person wrote, with one small adapter per format and backend.
