Repository: TypeScript
Issue: Add support for FORCE_COLOR environment variable to tsc
Labels: Suggestion,In Discussion

# Suggestion

<!--
  Please fill in each section completely. Thank you!
-->

## 🔍 Search Terms

<!--
  💡 Did you know? TypeScript has over 2,000 open suggestions!
  🔎 Please search thoroughly before logging new feature requests as most common ideas already have a proposal in progress.
  The "Common Feature Requests" section of the FAQ lists many popular requests: https://github.com/Microsoft/TypeScript/wiki/FAQ#common-feature-requests

  Replace the text below:
-->

FORCE_COLOR

## ✅ Viability Checklist

<!--
   Suggestions that don't meet all these criteria are very, very unlikely to be accepted.
   We always recommend reviewing the TypeScript design goals before investing time writing
   a proposal for ideas outside the scope of the project.
-->
My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

<!-- A summary of what you'd like to see added or changed -->


https://github.com/chalk/supports-color/blob/main/index.js

Among the npm/js ecosystem it is common to support overriding color output through an environment variable named `FORCE_COLOR`. The most commonly used implementation being the 'supports-color' library maintained by the 'chalk' team, linked above. The basic behavior is...

If `FORCE_COLOR` is `"0"` or `"false"` then force plain, uncolored output
If `FORCE_COLOR` is `"1"` or "true" then force 16 color ANSI output
If `FORCE_COLOR` is `"2"` then force 256 color ANSI output
If `FORCE_COLOR` is `"3"` then force full 24-bit RGB output

This ends up being particularly useful for writing tools that act as wrappers around `tsc`, which might spawn a `tsc` process and then display its output.

I think the tsc only ever uses 16 color output, which would simplify implementation a little bit.

## 📃 Motivating Example

<!--
  If you were announcing this feature in a blog post, what's a short explanation that shows
  a developer why this feature improves the language?
-->

The ability to run tsc in a task harness, while still getting colored output, without needing to do any weird argument/configuration injecting.

## 💻 Use Cases

<!--
  What do you want to use this for?
  What shortcomings exist with current approaches?
  What workarounds are you using in the meantime?
-->

The particular use case that I'm working on is a CLI tool that can invoke other CLI tools in parallel, such as ESLint, TSC, Prettier, Jest, TypeDoc, etc. The output of each process is piped into a set of buffers until the process exits, and then the buffer is piped out to stdout/stderr as appropriate. You get the speed benefits of running all the tooling in parallel, without needing to have 5+ terminals open to run them all manually, and without the output of each tool getting mixed with the output of others and becoming mangled and hard to read.

```
[jest]
--- Full color, continuous Jest output ---
[tsc]
--- Full color, continuous tsc output ---
```

etc.