-
Notifications
You must be signed in to change notification settings - Fork 812
Support FORCE_COLOR #2596
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support FORCE_COLOR #2596
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Implements support for the FORCE_COLOR environment variable in the tsc CLI so that colored output can be forced even when stdout is not a TTY, while still honoring NO_COLOR to disable colors.
Changes:
- Updated
defaultIsPrettyto considerNO_COLORandFORCE_COLORbefore falling back to TTY detection. - Extended
TestTscCommandlinewith scenarios that coverFORCE_COLORalone andNO_COLORplusFORCE_COLOR. - Added new command-line baselines to validate colored vs non-colored help output under these environment configurations.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
internal/execute/tsc/diagnostics.go |
Adjusts defaultIsPretty so NO_COLOR disables colors, FORCE_COLOR forces colors regardless of TTY, and TTY is used only as a fallback. |
internal/execute/tsctests/tsc_test.go |
Adds two new command-line test scenarios exercising FORCE_COLOR and the precedence of NO_COLOR over FORCE_COLOR. |
testdata/baselines/reference/tsc/commandLine/adds-color-when-FORCE_COLOR-is-set.js |
Baseline showing ANSI-colored help output when FORCE_COLOR is set. |
testdata/baselines/reference/tsc/commandLine/does-not-add-color-when-NO_COLOR-is-set-even-if-FORCE_COLOR-is-set.js |
Baseline confirming uncolored help output when NO_COLOR is set, even if FORCE_COLOR is also set. |
| if sys.GetEnvironmentVariable("NO_COLOR") != "" { | ||
| return false | ||
| } | ||
| if sys.GetEnvironmentVariable("FORCE_COLOR") != "" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's weird that we just look for any content (e.g. someone could write FALSE), but I don't know how other tools deal with this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They do what this does, more or less.
- https://github.com/alexeyraspopov/picocolors/blob/0e7c4af2de299dd7bc5916f2bddd151fa2f66740/picocolors.js#L3-L4 (truthy check)
- https://github.com/nodejs/node/blob/150d154bf1ba6cc28ca6276b94117b5a2813e6c8/lib/internal/tty.js#L126 (leveled, but truthy means a nonzero level)
- https://github.com/chalk/chalk/blob/aa06bb5ac3f14df9fda8cfb54274dfc165ddfdef/source/vendor/supports-color/index.js#L35 (same as node)
DanielRosenwasser
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If all tools deal with non-empty strings in this way, seems good.
Fixes #2540
picocolors, chalk, Node, etc, all support this.
Strada doesn't, but it seems to matter for people trying to use
tsgo, so, I think it's worth doing. And probably sticking in Strada if we want.