enhancement: Add --color flag to cerbos compile
#754
Conversation
By default, the output color level is detected from the environment by checking if stdout is a TTY and looking for various environment variables. See https://pkg.go.dev/github.com/jwalton/go-supportscolor for details. Signed-off-by: Andrew Haines <haines@cerbos.dev>
There was a problem hiding this comment.
LGTM. I am wondering whether we need the --color flag with all these options though. Wouldn't it be simpler to just have --no-color and if it's not defined, try to detect the colours supported by the TTY? In my mind, getting the colours absolutely right is not necessary for this use case. Do you think it's important to let users tune it?
I think it's important to at least be able to force color to be on even if stdout is not a tty. I think the colors enhance the legibility of the output, and I regularly find myself wanting tools to support this so that I can have color turned on for CI pipelines or within Docker builds. Is it important to be able to precisely specify whether you have basic, 256, or true color support? Perhaps less so. I initially wanted to just do Color *bool `negatable:""`so that you'd have Ultimately I was swayed by the fact that we already were detecting the precise color support for the colored JSON output, so it seemed reasonable to have an escape hatch for when that detection failed. This CLI flag style is widely supported in the Node ecosystem (it originally comes from supports-color, which is used by chalk). |
Description
Fixes #752 (the color level is now set for
ptermas well as thecolorlibrary, so--no-colorturns off all coloring in the tree output)Fixes #753
This PR introduces a complimentary
--colorflag in addition to the existing--no-color.With the default of
--color=auto, the output color level is detected from the environment by checking if stdout is a TTY and looking for various environment variables (see https://pkg.go.dev/github.com/jwalton/go-supportscolor for details).Otherwise, the output color level is set to:
--no-color,--color=false, or--color=never;--color,--color=true, or--color=always;--color=256; and--color=16m,--color=full, or--color=truecolorThis is basically a translation of
go-supportscolor's "sniff flags" functionality to make it compatible with Kong (which barfs on unknown flags, so we need to explicitly define them).