color

fatih/color is a lightweight Go library for producing colorized terminal output using ANSI SGR escape codes. It exposes a chainable Color type alongside a set of convenient helper functions (Red, Green, Cyan, and more) so developers can add colored text to CLI tools with minimal boilerplate, whether printing directly, wrapping an io.Writer, or embedding colored substrings inside larger formatted strings.

The package automatically detects whether stdout is a terminal and disables coloring for non-tty output, such as when piped to another program, and it also respects the NO_COLOR environment variable convention. It ships first-class Windows support via go-colorable and go-isatty, so the same code produces correct output across platforms without conditional logic in the caller.

What You Get

• Standard, hi-intensity, and 24-bit RGB foreground/background color support via Color and RGB/BgRGB constructors
• Drop-in helper functions like color.Red, color.Cyan, and their *String variants for zero-boilerplate colored output
• Automatic terminal detection that disables coloring on non-tty output or when NO_COLOR is set
• Cross-platform ANSI rendering on Windows via bundled go-colorable/go-isatty integration
• Composable Print/Fprint/Sprint function families, including PrintFunc/SprintFunc factories, for reusing a color across a codebase

Common Use Cases

• Highlighting warnings, errors, and success messages in CLI tool output
• Building colored log and status lines for build tools and test runners
• Embedding colored substrings inside larger formatted strings via SprintFunc
• Respecting user preferences and CI environments by auto-disabling color for piped or NO_COLOR output

Under The Hood

Architecture

fatih/color is intentionally flat: nearly all logic lives in a single color.go file, with color_windows.go adding a platform-specific init() for Windows virtual-terminal support and doc.go carrying package-level documentation. The core abstraction is the Color struct, a small value holding a slice of SGR Attribute values plus an optional per-instance noColor override; New() constructs one, Add()/AddRGB()/AddBgRGB() extend its parameter list, and format()/unformat() render the accumulated attributes into ANSI escape sequences on demand. Every print path (Print, Fprint, Sprint and their formatted/line variants) funnels through this same wrap()/format() machinery, and package-level helpers like Red or CyanString reuse cached Color instances via a mutex-guarded colorsCache map rather than reconstructing them per call. There’s no dependency injection or layering to speak of — the whole package is one cohesive unit built around a single mutable struct, which suits its narrow scope.

Tech Stack

The module targets Go 1.25 and depends on exactly three packages: github.com/mattn/go-colorable and github.com/mattn/go-isatty for terminal detection and Windows-safe ANSI writing, and golang.org/x/sys for the Windows console-mode syscalls used in color_windows.go’s init(). There’s no build tooling beyond the standard go toolchain, no runtime framework, and no external service integration — it’s a pure, dependency-light library meant to be imported directly.

Code Quality

Testing lives in color_test.go, which exercises every named color constant against its expected escape sequence and also drives visual/manual-inspection tests by writing through a buffered io.Writer. CI (.github/workflows/go.yml) runs go test -race, go vet, staticcheck, a go mod tidy diff check, and a full go build — a solid quality bar for a library this size. Naming is consistent and exported symbols carry doc comments; there’s no generics or heavy type machinery, which keeps the code straightforward to audit.

API Design The public API favors convenience over ceremony: users reach for package-level helpers (color.Red, color.CyanString) for one-off output, or construct a reusable *Color via New() when mixing attributes or calling repeatedly. PrintFunc/SprintFunc/FprintFunc factories let callers turn a configured Color into a plain function matching fmt’s own Print/Sprint/Fprint signatures, so integrating colored output into existing code requires no restructuring. The tradeoff is a fairly large exported surface (dozens of String and Hi variants) generated by hand rather than derived from a smaller primitive, but each function is self-explanatory and documented, keeping the learning curve low despite the surface area.