Closed heaths closed 1 year ago
@mislav sure, but to mock whether it's a TTY - which only checks stdout (redirects can be separate, of course, for stdout and stderr), whether color is enabled, etc., you end up wrapping the whole thing. And if you want to add in theme a la charmbracelet there's even more work. When cli/go-gh was initially proposed, I was hoping you'd port iostreams
from cli/cli - it's powerful - but ended up doing something similar with heaths/go-console that I've been using in pretty much all my CLI-related modules.
As for the name, whatever you guys like is fine. :) I just what was there public. Alternatively, what about just wrapping both into an IsColorEnabled
e.g.,
func IsColorEnabled() bool {
return os.Getenv("CLICOLOR_FORCE") != "" && os.Getenv("CLICOLOR_FORCE") != "0" ||
os.Getenv("NO_COLOR") == "" || os.Getenv("CLICOLOR") != "0")
}
That would seem a lot easier for external callers: a single check that wraps the logic of cli/cli.
Alternatively, what about just wrapping both into an
IsColorEnabled
I wanted to avoid wrapping too many checks in a single function call because that wouldn't be granular enough. For instance, color enabledness is not just a result of environment variables, but also whether stdout is a terminal.
I was hoping you'd port
iostreams
from cli/cli - it's powerful
The term
package is an extraction from iostreams but I intentionally didn't want to export everything from iostreams
because it's too large, unwieldy, and conflates too many concepts under a single level of abstraction.
Since IsColorDisabled - based on env vars - is public, also expose IsColorForced so the gamut of GitHub CLI env vars for color overrides are available to callers.
This is desirable when using something other than
term
which does not allow for mocking or otherwise capturing output. Since I use another library, access to APIs that encapsulate the various env vars the GitHub CLI (and extensions using this module) is ideal so my extensions can do a better job at matching the behavior of the CLI.