PHPBoyScout

TL;DR: A CLI tool wants pretty, coloured logs in a terminal. The same tool, running as a daemon in a container, wants structured JSON. If your packages import a concrete logger, switching between those two means touching every package. go-tool-base’s packages depend only on a logger.Logger interface, never a backend.... [Read More]

TL;DR: An error message that only states what went wrong leaves the user stuck. go-tool-base moved its error handling from go-errors to cockroachdb/errors specifically to separate two things that had been jammed together: the error’s identity, which is for the program, and its hint, which is for the human. Hints... [Read More]

TL;DR: Every command in a go-tool-base tool receives one argument: a *props.Props. It’s a dependency-injection container holding the logger, config, filesystem, assets, error handler and tool metadata. It is deliberately a concrete struct and deliberately not context.Context, because dependencies should be found by the compiler, not discovered at runtime. The... [Read More]

TL;DR: Go’s embed ships files inside your binary, but each embed.FS is an island, declared in one package. A modular CLI has many of them, and its features need to contribute to shared resources like the default config.yaml without editing a central file. props.Assets merges every registered embed.FS into one... [Read More]

TL;DR: A code generator that scaffolds your project is lovely on day one and a menace on day ninety, because the day you ask it to regenerate is the day it flattens every change you made. go-tool-base’s generator records a SHA-256 of every file it writes into a manifest. On... [Read More]