owo-colors

owo-colors lets Rust programs colorize terminal output without heap allocations or a mandatory dependency footprint, making it usable in no_std and embedded contexts as well as ordinary CLI tools. It works by wrapping values in generic or dynamic color/style types that implement the same std::fmt traits (Display, Debug, Octal, LowerHex, etc.) as the wrapped value, so coloring composes transparently with existing formatting code.

Colors and styles can be chosen at compile time via generics (zero runtime cost) or at runtime by value when the color isn’t known ahead of time. The crate also ships terminal-support detection — respecting NO_COLOR/FORCE_COLOR environment variables and TTY/CI checks — gated behind an optional supports-colors feature, so the core crate stays dependency-free by default.

What You Get

• An OwoColorize extension trait adding .green(), .on_red(), .bold(), .strikethrough() and similar combinators to any Display/Debug-implementing value
• Both compile-time (generic, zero-cost) and runtime (dynamic, value-based) color selection via dyn_colors.rs/dyn_styles.rs
• Support for all std::fmt formatter traits (Display, Debug, Octal, LowerHex, UpperHex, Pointer, Binary, LowerExp, UpperExp), not just Display
• Optional supports-colors feature for terminal-capability detection respecting NO_COLOR/FORCE_COLOR env vars and CI/TTY checks
• Zero-allocation, 100% safe, dependency-free core with an alloc feature flag for environments that do have a heap

Common Use Cases

• Adding colored, styled output to CLI tools without pulling in a heavyweight terminal-styling dependency
• Coloring diagnostic or log output in no_std/embedded Rust programs where heap allocation isn’t available
• Conditionally styling output only when the terminal supports it, respecting NO_COLOR conventions
• Migrating from the colored crate to a lower-overhead, no_std-compatible alternative

Under The Hood

Architecture: The crate centers on the OwoColorize trait (in src/lib.rs), implemented for any type via a blanket impl over std::fmt traits, which wraps the value in small marker structs. Compile-time coloring uses zero-sized generic color types defined in src/colors.rs/src/colors/, so the compiler can often optimize the styling to constant ANSI escape sequences. Runtime/dynamic coloring goes through src/dyn_colors.rs and src/dyn_styles.rs, which store the chosen color/style as a runtime value instead of a type parameter, at a small cost to zero-allocation guarantees. src/combo.rs and src/styled_list.rs provide combinators for composing multiple styles and styling collections.

Tech Stack: Pure Rust, MSRV 1.81, edition = 2021, with zero mandatory dependencies. The optional supports-colors feature pulls in both supports-color v2 and v3 (aliased as supports-color-2) to interoperate with crates depending on either version. build.rs gates newer-Rust features behind version detection to preserve the conservative MSRV policy described in the README (12-month support window, bumped only on new minor versions).

Code Quality: Tests live in src/tests.rs alongside the implementation (typical for small, focused Rust crates), and the crate explicitly advertises “100% safe code” with no unsafe blocks. rustfmt.toml and release.toml show attention to consistent formatting and a defined release process. With 802 stars, 25 contributors, and a stable v4 API line, the crate is mature but sees only light day-to-day maintenance (last commit several months prior to this analysis).

API Design: The core interaction pattern — value.green(), value.on_red(), value.bold() — reads naturally at the call site and requires no setup or wrapper boilerplate, since OwoColorize is implemented generically for any formattable type. Chaining multiple style calls (4.fg::<Black>().bg::<Yellow>()) composes cleanly, and the if_supports_color(Stream::Stdout, |text| ...) combinator keeps terminal-capability checks out of the hot styling path.