I'm up for this, but only if we can also do bulletproof TTY detection. I'd much rather have uncolored logs than see escape codes in non-interactive environments.

We should use existing terminal detection, I've seen https://github.com/mattn/go-isatty before, and the Go x/ package contains one too:https://godoc.org/golang.org/x/crypto/ssh/terminal#IsTerminal

I'd suggest having an option to force colored output on or off (regardless of TTY detection). We have CI servers, for example, which can handle colored output nicely, but are non-interactive.

I'm happy to look at PRs for this, but really don't want to depend on any pre-1.0 or unversioned libraries.

Isn't this fixed with the inclusion of #307?

@nikolavp maybe OP is asking for CapitalColorLevelEncoder to be used by NewDevelopment by default?

OP's intention was that the default interactive development experience looks less like a wall of undifferentiated text; one of the options was to enable colors by default.

Honestly, we still haven't found a solution for this that I like. Internally, our preference is to push fragile/complex-ish things like TTY detection to a config layer that's company-specific. Churn in the behavior of that package doesn't affect the stability of zap itself.

@akshayjshah I will be working on this. Is there something I need to keep in mind before starting out?

I implemented apex-like console colored encoder (here white is used for debug, blue for info, red for error and yellow for warn).

maybe this month I will publish as a separate reusable package.

But problem is that currently nested logger (With ) implemented in an efficient manner — instead of passing inherited fields to EncodeEntry, these fields encoded on With call and then added to final result as byte array. But colored renderer cannot work in this way, because color is not yet known (depends on level). As solution, I encode name and value to separate string (key) and byte (value) arrays. A little bit inefficient, but it is the only solution (well, the most expensive part — encode value, is done as before, so, only memory usage a little bit increased).

Hey @develar do you have any updates on this issue?