You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For context, we just migrated Babel from Chalk to picocolors and found this difference. For now we are going to roll our own color detection logic to preserve the Node.js-like behavior.
The text was updated successfully, but these errors were encountered:
I'm considering switch to https://nodejs.org/api/tty.html#writestreamhascolorscount-env that seems to be available since Node.js v10.16. I will try to find some tests to see how it works with FORCE_COLOR variable and will make sure too keep this behavior in mind. There's probably a small patch I can make in the meantime for v1 to avoid breaking changes.
For what is worth, I tried running a totally unscientific poll on Twitter and it seems like people are split on the behavior of FORCE_COLOR=0. While I still think that it's good for Node.js libraries to align with Node.js, changing what FORCE_COLOR=0 does should probably be considered a breaking change.
Node.js allows disabling color by passing
FORCE_COLOR=0
(https://nodejs.org/api/tty.html#writestreamgetcolordepthenv). Would you be open to a PR checking ifFORCE_COLOR
is 0?For context, we just migrated Babel from Chalk to picocolors and found this difference. For now we are going to roll our own color detection logic to preserve the Node.js-like behavior.
The text was updated successfully, but these errors were encountered: