README
¶
go-boost
Small, focused Go utilities. One module, one import path, one version.
go get github.com/zephos-zero/go-boost
Packages
Every package is independently importable. The Deps column is the honest cost of importing
it — Go's module graph pruning means you only acquire the dependencies of the
packages you actually import, so importing errs costs you nothing but errs.
| Package | What it is | Deps |
|---|---|---|
errs |
Typed, categorized errors with errors.Is/As compatibility and exit-code mapping. The foundation the others build on. |
none |
buildinfo |
A program's name and version as one renderable value; Resolve reconciles -ldflags with go install path@version. |
none |
xdg |
Cross-platform base directories (XDG on Unix, native dirs on Windows). | errs |
render |
One output writer honoring text / json / yaml, so a tool's faces can't drift. |
errs, yaml.v3 |
config |
Environment-based configuration loading with validation hooks. | errs, godotenv, envconfig |
schema |
Validate a YAML/JSON document against a JSON Schema, then unmarshal it — validation before unmarshal. | errs, jsonschema/v6, sigs.k8s.io/yaml, yaml.v3 |
Why one module
go-boost is deliberately a single Go module rather than one module per package.
The usual argument for splitting — "I only wanted errs and my go.mod filled up with
dependencies" — describes a real problem that Go fixed in 1.17 with module graph pruning.
A module importing only errs gets exactly one require line and none of config's
dependencies. That is measured, not assumed.
Splitting would also make the library harder to navigate, not easier: pkg.go.dev renders one module as a single indexed page, and N modules as N disconnected ones. Modules are a release/versioning boundary, not a taxonomy.
So a package earns its own module for exactly one reason: it needs an independent version
cadence — for example, errs committing to v1.0 stability while the rest of the library is
still moving. Never merely because it has dependencies.
See CONTRIBUTING.md for what may enter this library, and docs/RELEASING.md for how it ships.
License
See LICENSE.
Directories
¶
| Path | Synopsis |
|---|---|
|
Package buildinfo carries a program's identity and version as a single value that renders across text, JSON, and YAML, so every binary of a multi-face tool reports itself the same way.
|
Package buildinfo carries a program's identity and version as a single value that renders across text, JSON, and YAML, so every binary of a multi-face tool reports itself the same way. |
|
Package config provides lightweight configuration loading from environment variables with validation support.
|
Package config provides lightweight configuration loading from environment variables with validation support. |
|
Package errs provides structured error categorization with code-based classification, compatible with the standard library's errors.Is/errors.As.
|
Package errs provides structured error categorization with code-based classification, compatible with the standard library's errors.Is/errors.As. |
|
Package render writes a value to an io.Writer in a selected output format (text, JSON, or YAML).
|
Package render writes a value to an io.Writer in a selected output format (text, JSON, or YAML). |
|
Package schema validates a YAML or JSON document against a JSON Schema and, only if it is valid, unmarshals it into a Go value.
|
Package schema validates a YAML or JSON document against a JSON Schema and, only if it is valid, unmarshals it into a Go value. |
|
Package xdg resolves per-user base directories — data, state, and config — mapping the XDG Base Directory Specification on Unix to the equivalent native locations on Windows (%LocalAppData% / %AppData%).
|
Package xdg resolves per-user base directories — data, state, and config — mapping the XDG Base Directory Specification on Unix to the equivalent native locations on Windows (%LocalAppData% / %AppData%). |