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.

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.

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.

yamldoc is the editing half of YAML for Go: change one key and every byte you did not touch comes back exactly as it went in, comments included. It now has an engine of its own, and the numbers to show why.

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.

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.

I built a boundary so I wouldn't have to move my config package. Then I moved it anyway, and the boundary is the only reason that didn't hurt.

A post hit Hacker News and the analytics showed pages far heavier than a static site should be. The cover images were the payload.

Configuration for a Go CLI: precedence of flags over env over files, per-command embedded defaults, layered config merging and a strict mode.

Hot-reloading configuration: watch the file, re-read it, swap it in atomically and notify observers, without restarting a long-running service.

Config loaders ignore keys they do not recognise, so a typo runs on the old value. Deriving a validation schema from struct tags to catch it.
