Should handle `FORCE_COLOR` environment variable

[so1ve]

Current implementation

typescript-go/internal/execute/tsc/diagnostics.go

Lines 46 to 48 in 9799455

	func defaultIsPretty(sys System) bool {
	return sys.WriteOutputIsTTY() && sys.GetEnvironmentVariable("NO_COLOR") == ""
	}

tries to determine whether the terminal is a TTY. This prevents us from using exec to get colored help text, which makes the output very ugly when creating wrappers for tsgo (such as vue-tsgo).

[jakebailey]

The old codebase didn't do this either: https://github.com/search?q=repo%3Amicrosoft%2FTypeScript%20force_color&type=code

Why is this needed now?

[so1ve]

vue-tsc runs tsc directly by calling require(tscPath); while vue-tsgo has its own cli, we want to get colored and formatted tsgo help text, appended to our cli's own help text, just like https://github.com/privatenumber/tsx.

[jakebailey]

picocolors, chalk, even node do support this, so it would make sense to, I'm just noting that TS has never supported it, so it's surprising to start needing it now.

[silverwind]

Chalk uses https://github.com/chalk/supports-color and there exists a go port of it as well at https://github.com/jwalton/go-supportscolor (but outdated). I bullet-proof color support is needed, I can recommend these packages.

[jakebailey]

We won't need that; it's just an environment variable check.

[silverwind]

Yeah, for FORCE_COLOR support alone, the env var check alone is enough. For better automatic color support without FORCE_COLOR, things get complicated. But I guess having FORCE_COLOR is one simple way avoid that and delegate to the user to set the variable where needed.

[jakebailey]

I don't think we need anything more fancy (see how picocolors does it). We wouldn't take on a dep for this anyhow, since we need to be able to test it, via our own host abstraction.

[silverwind]

Yeah FORCE_COLOR support would be sufficient to get color output in cases where stdout is not a TTY, like on CI environments.