Right now, it seems fixated on process.stdout. I guess the same is true for chalk. Dang.

The check for VSCODE_PID to support the VSCode debugger in the following line breaks ansi color code suppression when redirecting stdout or stderr in the VSCode integrated terminal: https://github.com/chalk/supports-color/blob/master/index.js#L52

For example, the following commands in a normal terminal produces the expected results:

$ node -p "process.stdout.isTTY"
true
$ node -p "process.stdout.isTTY" | cat
undefined
$ node -p "require('supports-color').stdout"
{ level: 3, hasBasic: true, has256: true, has16m: true }
$ node -p "require('supports-color').stdout" | cat
false

However, in VSCode's integrated terminal, the following output occurs:

$ node -p "process.stdout.isTTY"
true
$ node -p "process.stdout.isTTY" | cat
undefined
$ node -p "require('supports-color').stdout"
{ level: 3, hasBasic: true, has256: true, has16m: true }
$ node -p "require('supports-color').stdout" | cat
{ level: 1, hasBasic: true, has256: false, has16m: false }

The VSCODE_PID check is causing the last line above to report level 1 support, rather than the expected level 0 during a redirection. A real world case in which this is a problem can be demonstrated by running the following:

Terminal:

$ node -p "o=JSON.stringify({foo:'bar'});if(require('chalk').enabled){require('cardinal').highlight(o)}else{o}" | jq
{
  "foo":"bar"
}

VSCode:

$ node -p "o=JSON.stringify({foo:'bar'});if(require('chalk').enabled){require('cardinal').highlight(o)}else{o}" | jq
parse error: Invalid numeric literal at line 1, column 2

By default PuTTY reports its terminal type as 'putty'. supports-color doesn't recognize this, so it reports a PuTTY terminal as not supporting color. PuTTY does support color, though - you can set the terminal-type string can be set to 'xterm-256' in PuTTY's options and colors work fine.

Emacs M-x shell runs the shell in an environment where the TERM variable is set to dumb, which informs the shell and applications that the terminal does not support any terminal control escape sequences.

While you have code to handle the dumb setting, both the Windows platform processing and the TERM_PROGRAM are processed first.

For instance on macOS,

$ cd /path/to/mocha/node_modules
$ TERM=dumb node -e "var tty = require('./supports-color'); console.log(tty.stdout);"
{ level: 2, hasBasic: true, has256: true, has16m: false }
$ TERM_PROGRAM= TERM=dumb node -e "var tty = require('./supports-color'); console.log(tty.stdout);"
false

Mocha is getting publicly blamed for this. Suggestions?

Hello,

I'm messing around with React Native and I wanted to try using chalk to help make some of the logs more clear. I'm running into an issue though at the import/require step.

If I try import chalk from 'chalk'; or const chalk = require('chalk'); I receive the following error:

Here are the output of the React Packager:

[12/28/2016, 3:59:04 PM] <START> Requesting bundle bundle_url: /index.ios.bundle?platform=ios&dev=true&minify=false
[12/28/2016, 3:59:04 PM] <END>   Requesting bundle bundle_url: /index.ios.bundle?platform=ios&dev=true&minify=false (25ms)
[12/28/2016, 3:59:04 PM] <START> Symbolicating
[12/28/2016, 3:59:04 PM] <END>   Symbolicating (319ms)
[12/28/2016, 3:59:04 PM] <START> Symbolicating
[12/28/2016, 3:59:05 PM] <END>   Symbolicating (306ms)

If I'm following the stack trace correctly its complaining about lines 2-4 in supports-color/index.js:

var argv = process.argv;

var terminator = argv.indexOf('--');

Further info:
OS: OSX v10.11.6
Node: v5.9.1
NPM: v3.10.8
React Native: v0.39.2
Chalk: v^1.1.3

I am trying to deploy my Node.js app in Heroku. The build process was successful but upon checking the app, it crashed. I kept on encountering this error pointing to supports-color package.

See CrabDude/trycatch#35

I converted trycatch to use chalk, but having reviewed the has-color code, it seems to suffer from the same bug/assumption.

const chalk = require('chalk');
const supportsColor = require('supports-color');

const str1 = 'str1';

console.log(str1, str1.length); // clean
const str2 = chalk.red('str2');
console.log(str2, str2.length); // chalk styled

console.log(str1, str1.length); // clean
const str3 = '\x1b[42mstr3\x1b[0m';
console.log(str3, str3.length); // my styled

console.log(str1, str1.length); // clean

console.log('supports color:', supportsColor);

process.exit(0);

Above is executed on the two following below.

On my local computer terminal:

On GitLab runner:

As you can see it does support colors, as it is showing colors. So I'm guessing this is a bug.

We are using supports-color in our npm based buildtask in order to create jsdoc of our project. Since January 2019 This process does not work anylonge we get the message:

FATAL: Unable to load template: Unexpected token {

We found out that the problem is casued by supports-color\index.js. Since version 6.0 you are using

const{env} = process in line 5.

Before you had

const env = process

Can you please tell me what to do to use supports-color again ?

We are using the following maven plugin configuration to trigger the js doc generation

Best Regards Robert Eberhardt

TERM has an endless list of possible values:

The correct way would be to look up the terminal information given the TERM environment variable and see what capabilities the terminal has. This includes what kind of underline/overline it has, whether or not the terminal supports color at all, how many colors it supports, and (if I read the man page correctly) even the escape character that should be used.

I understand a lot of that information isn't pertinent to supports-color specifically, but the color support bits do.

Currently, we're just testing for a few of the common TERM values via regex.

Hi,

A Node.js process launched from IDE has process.stdout.isTTY always set to false, because the Node.js process is started with redirected streams. Unfortunately, AFAIK, there is no way to set it to true.
So, to enable colors users should specify --color command line flag manually.
IDE can improve the situation and add --color flag automatically. But it seems a bit unsafe for me, because it isn't clear where the safe place for --color flag is (specifying --color as the first argument might be incorrect for some apps and specifying it as the last one might be incorrect for others).

Possibly safer way would be to introduce a new environment variable (like ENABLE_ANSI_COLORS) and check for it before checking for process.stdout.isTTY:

    if (/^1|^true|^yes|always/i.test(process.env.ENABLE_ANSI_COLORS)) {
        return true;
    }
    if (process.stdout && !process.stdout.isTTY) {
        return false;
    }

Another way is to place check for COLORTERM environment variable before checking for process.stdout.isTTY, but I'm not sure it wouldn't break some use-cases.

Thanks.

The API surface has changed since version 4.0.0, but the browser implementation did not change with it.

I find myself running node foo.js --color=always or node foo.js --color=true because other commands like npm and non-node tools have those conventions.

I then try --color and am reminded that that's how node + chalk works.

I'd be cool if supports-color supported other ways to turn color on at the CLI level.

I just upgraded MacOS to Mojave. And my terminal TERM_PROGRAM_VERSION became 421. And the following line seems not working on my machine.

    TypeError: (env.TERM_PROGRAM_VERSION || "").split is not a function

      at supportsColor (node_modules/jest-each/node_modules/supports-color/index.js:92:61)
      at Object.require.extensions.(anonymous function) [as .js] (node_modules/babel-register/lib/node.js:152:7)

For predictability when testing tools that output color.

I'm open to suggestions on the best way to do this.

Rewire adds a __get__ and __set__ to the internals of modules for people to use in tests.

Since supports-color's index.js file is wrapped in an IIFE, when it is required via a file that was 'rewired', we get the following error:

TypeError: Cannot assign to read only property '__get__' of true

When running NPM scripts in Git Bash for Windows / MinGW64, chalk/supports-color returns false, even though chalk/ansi-styles can output colors. (See: https://github.com/MarkTiedemann/supports-color-bug)

If node is run directly, without NPM scripts, supports-color correctly returns true.

If used with cmder instead of Git Bash for Windows / MinGW64, both with and without NPM scripts, it correctly returns true.

Running latest Node, NPM, and Git for Windows version.

EDIT: Not sure how this is related to #36. Is this a wontfix as well?

So that all CLIs based on this library (would make a lot) becomes directly compatible with no-color manifesto, how about adding support for NO_COLOR env variable? If ≠ empty string, then it sets forceColor to false.

It occured an error when use it with create-react-app. because of socre code wrote with ES6, can you please release an ES5 libs ?

it would be good to disable coloring if process runes from TeamCity. Here is node -p 'process.env' output from TeamCity build step:

{
TEAMCITY_BUILD_PROPERTIES_FILE: '/opt/teamcity/buildagetnt/temp/buildTmp/teamcity.build2602458914988989541.properties',
TERM: 'linux',
JRE_17_x64: '/usr/lib/jvm/jre',
TMPDIR: '/opt/teamcity/buildagetnt/temp/buildTmp',
TEAMCITY_CAPTURE_ENV: '"/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.85.x86_64/jre/bin/java" -jar "/opt/teamcity/buildagetnt/plugins/environment-fetcher/bin/env-fetcher.jar"',
TEAMCITY_VERSION: '9.0.5 (build 32523)',
JRE_HOME: '/usr/bin/..',
TEMP: '/opt/teamcity/buildagetnt/temp/buildTmp',
TEAMCITY_BUILDCONF_NAME: 'api api',
BUILD_VCS_NUMBER: '95fb89fd9d28',
NLSPATH: '/usr/dt/lib/nls/msg/%L/%N.cat',
PATH: '/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin:/usr/local/lib',
RUNLEVEL: '3',
runlevel: '3',
_: '/usr/bin/node',
PWD: '/opt/teamcity/buildagetnt/work/abeaf100e9e82338',
LANGSH_SOURCED: '1',
DOCKER_CONFIG: '/usr/local/etc/.docker',
TEAMCITY_GIT_PATH: '/usr/bin/git',
LANG: 'en_US.UTF-8',
PREVLEVEL: 'N',
previous: 'N',
XFILESEARCHPATH: '/usr/dt/app-defaults/%L/Dt',
CONSOLETYPE: 'serial',
BUILD_VCS_NUMBER_feedbackforum_feedbackforumapi: '95fb89fd9d28',
HOME: '/root/',
SHLVL: '4',
TEAMCITY_PROCESS_FLOW_ID: '818047604373',
UPSTART_INSTANCE: '',
TMP: '/opt/teamcity/buildagetnt/temp/buildTmp',
UPSTART_EVENTS: 'runlevel',
BUILD_NUMBER: '150',
JRE_17: '/usr/lib/jvm/jre',
UPSTART_JOB: 'rc',
TEAMCITY_PROJECT_NAME: '10 tests',
COMPOSER_HOME: '/usr/local/bin',
TEAMCITY_PROCESS_PARENT_FLOW_ID: ''
}

In similar situation xUnit runner uses TEAMCITY_PROJECT_NAME env variable to detect that it running from TeamCity

Right now this module just exports a Boolean, which is really lame, because it pretty much makes this request impossible, but I want to ask anyway to put my interest in. Right now this module just checks process.stdout to see if it is a TTY. Would be awesome to have a function to provide a stream to like supportsColor(process.stderr).

Chalk uses colors when node launched as Upstart daemon http://upstart.ubuntu.com/cookbook/#console-log

Sample of upstart config:

start on (started network-interface
          or started network-manager
          or started networking)

stop on (stopping network-interface
         or stopping network-manager
         or stopping networking)

respawn
env NODE_ENV=production

chdir /home/ubuntu/app
setuid ubuntu
setgid ubuntu

exec npm start

Logs are located in /var/log/upstart/app.log and they includes colors.

Stdout are detected by supports-color as TTY

chalk/chalk#48

Any ideas how to detect upstart?

supports-semigraphics was inspired by this library and might be informative to others if mentioned in the readme.

It enters here, before entering here.

Which means it ends with 16 color support, instead of 256.

echo $COLORTERM outputs truecolor.

Reordering the ifs fixes the issue, but wondering if there's a better solution.

Context: this and this.

/cc @Qix- @sindresorhus

Although the heuristics for inspecting process.argv via hasFlag() are pretty reasonable, they are by no means foolproof and can lead to false positives and negatives. It would be nice if it were possible to use the functionality of supportLevel() without any of the hasFlag() logic. I believe the remaining logic would be a function of:

• process.env.CI
• process.env.TEAMCITY_VERSION
• process.env. COLORTERM
• process.env.TERM
• process.stdout
• process.platform

It would be even more flexible if it were possible to pass in the process object so that it could be mocked and/or used from another process.

getColorDepth() was added in Node.js 9.9.0 and hasColors() and FORCE_COLOR=0|1|2|3 to Node.js 11.13.0. They are directly based on this module's code.

supports-color brings extra features:

• supports CLI flag [--no]-color[s]
• supports browsers (which always default to "no colors")
• hasColors() is undefined if stream.isTTY is not true, i.e. one needs to do stream.hasColors !== undefined && stream.hasColors()

On the other hand, getColorDepth() and hasColors():

• are in core Node.js
• supports more fine grained color detection logic. See the current code. They basically handle much more environment variables cases.

My question is: wouldn't it make sense to do the following?

• export ponyfills of getColorDepth() and hasColors(). Basically, just copy/pasting the code. If the Node.js running version supports those functions, they can be directly used. Those ponyfills could be removed in the future once Node.js supported versions are upgraded.
• use those methods instead of the current detection logic.

I found this issue using chalk, but it's color support related so I thought it was a better idea to submit my issue here.

Check out the following code. The same string is colored using the default chalk instance, a chalk forced to level 2, and a chalk forced to level 3.

// Default chalk
let chalk = require('chalk');
console.log(chalk.supportsColor);
print(chalk);

// 256 colors chalk
let ch256 = new chalk.constructor({level: 2});
print(ch256);

// Truecolor chalk
let ch16m = new chalk.constructor({level: 3});
print(ch16m);

function print(c) {
    let result = '';
    for(let i =0; i < 60; i++){
        result += c.rgb(255 - 2*i, 0, 2*i)('█');
    }
    console.log('    ' + result);
}

The supportsColor returns this: { level: 2, hasBasic: true, has256: true, has16m: false } , so it looks like my terminal does not support Truecolor.

However, the printed colors look like that:

It is clear that my terminal actually supports Truecolor. Why is it not detected ?

What if I always force level 3 in my code ? Can it impact users who only support 256 colors ?

Thanks a lot

supports-color version: 2.0.0
chalk version: 2.0.1
Ubuntu 16.04.2 LTS
gnome-terminal 3.18.3

instead of just process.env.CI.

See https://blog.jetbrains.com/teamcity/2015/07/teamcity-9-1-release-truly-historical-and-very-personal-builds/

Say I writing a cli task runner that runs node processes with spawn. If I want to pipe the output to the stdout (so I can intercept the data and process if necessary), tty will not be set. And then you have to do some complicated stuff with drawback like native deps (https://stackoverflow.com/questions/31866207/spawning-a-child-process-with-tty-in-node-js) to emulate a tty (or maybe there is an easier way).

So isTTY doesn't seem like is prevents supporting colors. Or is this the only way to detect cat file | node app or something?

Don't know if it's possible to handle this case, but I have syntax highlight script and I'm adding support for terminals that don't suport 256 colors, like ansi term from emacs, and I'm testing this from xterm on GNU/Linux:

prism.js -f prism.js -l javascript | less -R

and when I've added console.log(supportsColor); I've got false even that 256 colors work.

platform: running bash in mintty.exe. The color escape codes work fine when you force them via the --color argv / CLI option, but that's undesirable.
When I look at the reported ENV, SESSIONNAME pops out: checking for that one might solve the issue.

(Indeed it did in a quickly patched version of supports-color 👍 )

Here's a (minimally redacted) process.env dump from the interactive node shell for your perusal:

> console.log(process)
process {
  title: ' ',
  version: 'v8.1.2',
  moduleLoadList:
   [ 'Binding contextify',
     'Binding natives',
     'Binding config',
     'NativeModule events',
     'Binding async_wrap',
     'Binding icu',
     'NativeModule util',
     'Binding uv',
     'NativeModule buffer',
     'Binding buffer',
     'Binding util',
     'NativeModule internal/util',
     'NativeModule internal/errors',
     'Binding constants',
     'NativeModule internal/buffer',
     'NativeModule timers',
     'Binding timer_wrap',
     'NativeModule internal/linkedlist',
     'NativeModule async_hooks',
     'NativeModule assert',
     'NativeModule internal/process',
     'NativeModule internal/process/warning',
     'NativeModule internal/process/next_tick',
     'NativeModule internal/process/promises',
     'NativeModule internal/process/stdio',
     'NativeModule internal/url',
     'NativeModule internal/querystring',
     'NativeModule querystring',
     'Binding url',
     'NativeModule tty',
     'NativeModule net',
     'NativeModule stream',
     'NativeModule internal/streams/legacy',
     'NativeModule _stream_readable',
     'NativeModule internal/streams/BufferList',
     'NativeModule internal/streams/destroy',
     'NativeModule _stream_writable',
     'NativeModule _stream_duplex',
     'NativeModule _stream_transform',
     'NativeModule _stream_passthrough',
     'NativeModule internal/net',
     'Binding cares_wrap',
     'Binding tty_wrap',
     'Binding tcp_wrap',
     'Binding pipe_wrap',
     'Binding stream_wrap',
     'NativeModule internal/repl',
     'NativeModule readline',
     'NativeModule internal/readline',
     'NativeModule repl',
     'NativeModule internal/module',
     'NativeModule vm',
     'NativeModule path',
     'NativeModule fs',
     'Binding fs',
     'Binding fs_event_wrap',
     'NativeModule internal/fs',
     'NativeModule console',
     'Binding signal_wrap',
     'NativeModule module',
     'NativeModule domain',
     'NativeModule os',
     'Binding os',
     'NativeModule string_decoder',
     'Binding inspector' ],
  versions:
   { http_parser: '2.7.0',
     node: '8.1.2',
     v8: '5.8.283.41',
     uv: '1.12.0',
     zlib: '1.2.11',
     ares: '1.10.1-DEV',
     modules: '57',
     openssl: '1.0.2l',
     icu: '59.1',
     unicode: '9.0',
     cldr: '31.0.1',
     tz: '2017b' },
  arch: 'x64',
  platform: 'win32',
  release:
   { name: 'node',
     sourceUrl: 'https://nodejs.org/download/release/v8.1.2/node-v8.1.2.tar.gz',
     headersUrl: 'https://nodejs.org/download/release/v8.1.2/node-v8.1.2-headers.tar.gz',
     libUrl: 'https://nodejs.org/download/release/v8.1.2/win-x64/node.lib' },
  argv: [ 'C:\\Program Files\\nodejs\\node.exe' ],
  execArgv: [],
  env:
   { ACLOCAL_PATH: '/mingw64/share/aclocal:/usr/share/aclocal',
     ALLUSERSPROFILE: 'C:\\ProgramData',
     APPDATA: 'C:\\Users\\Ger\\AppData\\Roaming',
     CLASS_PATH: '.',
     COMMONPROGRAMFILES: 'C:\\Program Files\\Common Files',
     'CommonProgramFiles(x86)': 'C:\\Program Files (x86)\\Common Files',
     CommonProgramW6432: 'C:\\Program Files\\Common Files',
     COMSPEC: 'C:\\Windows\\system32\\cmd.exe',
     CONFIG_SITE: '/mingw64/etc/config.site',
     DISPLAY: 'needs-to-be-defined',
     FPS_BROWSER_APP_PROFILE_STRING: 'Internet Explorer',
     FPS_BROWSER_USER_PROFILE_STRING: 'Default',
     HOME: 'C:\\Users\\Ger',
     HOMEDRIVE: 'C:',
     HOMEPATH: '\\Users\\Ger',
     INFOPATH: '/usr/local/info:/usr/share/info:/usr/info:/share/info',
     JAVA_HOME: 'C:\\Program Files\\Java\\jdk1.8.0_121',
     LANG: 'en_US.UTF-8',
     LOCALAPPDATA: 'C:\\Users\\Ger\\AppData\\Local',
     MANPATH: '/mingw64/share/man:/usr/local/man:/usr/share/man:/usr/man:/share/man',
     MINGW_CHOST: 'x86_64-w64-mingw32',
     MINGW_PACKAGE_PREFIX: 'mingw-w64-x86_64',
     MINGW_PREFIX: '/mingw64',
     MSYSCON: 'mintty.exe',
     MSYSTEM: 'MINGW64',
     MSYSTEM_CARCH: 'x86_64',
     MSYSTEM_CHOST: 'x86_64-w64-mingw32',
     MSYSTEM_PREFIX: '/mingw64',
     NUMBER_OF_PROCESSORS: '8',
     NVM_HOME: 'C:\\Users\\Ger\\AppData\\Roaming\\nvm',
     NVM_SYMLINK: 'C:\\Program Files\\nodejs',
     ORIGINAL_PATH: 'C:\\Program Files (x86)\\STMicroelectronics\\st_toolset\\asm;C:\\ProgramData\\Oracle\\Java\\javapath;C:\\Windows\\system32;C:\\Windows;C:\\
Windows\\System32\\Wbem;C:\\Windows\\System32\\WindowsPowerShell\\v1.0;C:\\Program Files\\Git\\cmd;C:\\Program Files (x86)\\Skype\\Phone;C:\\Users\\Ger\\AppData
\\Roaming\\nvm;C:\\Program Files\\nodejs;C:\\Program Files\\TortoiseGit\\bin;C:\\Program Files\\Calibre2;C:\\Ruby23\\bin;C:\\Program Files\\Java\\jdk1.8.0_121\\
bin;C:\\Users\\Ger\\bin\\java_tools\\bin;C:\\Users\\Ger\\AppData\\Local\\Microsoft\\WindowsApps;C:\\Users\\Ger\\AppData\\Roaming\\npm;C:\\Users\\Ger\\AppData\\R
oaming\\nvm;C:\\Program Files\\nodejs;C:\\Program Files\\SDCC\\bin',
     ORIGINAL_TEMP: '/tmp',
     ORIGINAL_TMP: '/tmp',
     OS: 'Windows_NT',
     PATH: 'C:\\Users\\Ger\\bin;C:\\git-sdk-64\\mingw64\\bin;C:\\git-sdk-64\\usr\\local\\bin;C:\\git-sdk-64\\usr\\bin;C:\\git-sdk-64\\usr\\bin;C:\\Program Files
 (x86)\\STMicroelectronics\\st_toolset\\asm;C:\\ProgramData\\Oracle\\Java\\javapath;C:\\Windows\\system32;C:\\Windows;C:\\Windows\\System32\\Wbem;C:\\Windows\\S
ystem32\\WindowsPowerShell\\v1.0;C:\\Program Files\\Git\\cmd;C:\\Program Files (x86)\\Skype\\Phone;C:\\Users\\Ger\\AppData\\Roaming\\nvm;C:\\Program Files\\node
js;C:\\Program Files\\TortoiseGit\\bin;C:\\Program Files\\Calibre2;C:\\Ruby23\\bin;C:\\Program Files\\Java\\jdk1.8.0_121\\bin;C:\\Users\\Ger\\bin\\java_tools\\b
in;C:\\Users\\Ger\\AppData\\Local\\Microsoft\\WindowsApps;C:\\Users\\Ger\\AppData\\Roaming\\npm;C:\\Users\\Ger\\AppData\\Roaming\\nvm;C:\\Program Files\\nodejs;
C:\\Program Files\\SDCC\\bin;C:\\git-sdk-64\\usr\\bin\\site_perl;C:\\git-sdk-64\\usr\\bin\\vendor_perl;C:\\git-sdk-64\\usr\\bin\\core_perl',
     PATHEXT: '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC',
     PKG_CONFIG_PATH: '/mingw64/lib/pkgconfig:/mingw64/share/pkgconfig',
     PROCESSOR_ARCHITECTURE: 'AMD64',
     PROCESSOR_IDENTIFIER: 'Intel64 Family 6 Model 60 Stepping 3, GenuineIntel',
     PROCESSOR_LEVEL: '6',
     PROCESSOR_REVISION: '3c03',
     ProgramData: 'C:\\ProgramData',
     PROGRAMFILES: 'C:\\Program Files',
     'ProgramFiles(x86)': 'C:\\Program Files (x86)',
     ProgramW6432: 'C:\\Program Files',
     PS1: '\\[\\033]0;$TITLEPREFIX:${PWD//[^[:ascii:]]/?}\\007\\]\\n\\[\\033[32m\\]\\u@\\h \\[\\033[35m\\]$MSYSTEM \\[\\033[33m\\]\\w\\[\\033[36m\\]`__git_ps1`\
\[\\033[0m\\]\\n$ ',
     PSModulePath: 'C:\\Program Files\\WindowsPowerShell\\Modules;C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\Modules',
     PUBLIC: 'C:\\Users\\Public',
     SESSIONNAME: 'Console',
     SHELL: 'C:\\git-sdk-64\\usr\\bin\\bash.exe',
     SHLVL: '1',
     SSH_ASKPASS: '/mingw64/libexec/git-core/git-gui--askpass',
     SYSTEMDRIVE: 'C:',
     SYSTEMROOT: 'C:\\Windows',
     TEMP: 'C:\\Users\\Ger\\AppData\\Local\\Temp',
     TMP: 'C:\\Users\\Ger\\AppData\\Local\\Temp',
     TMPDIR: 'C:\\Users\\Ger\\AppData\\Local\\Temp',
     TZ: 'Europe/Amsterdam',
     USERNAME: 'Ger',
     USERPROFILE: 'C:\\Users\\Ger',
     WINDIR: 'C:\\Windows',
     _: '/usr/bin/winpty' },
  pid: 86288,
  features:
   { debug: false,
     uv: true,
     ipv6: true,
     tls_npn: true,
     tls_alpn: true,
     tls_sni: true,
     tls_ocsp: true,
     tls: true },
  _needImmediateCallback: false,
  execPath: 'C:\\Program Files\\nodejs\\node.exe',
  debugPort: 9229,
  _startProfilerIdleNotifier: [Function: _startProfilerIdleNotifier],
  _stopProfilerIdleNotifier: [Function: _stopProfilerIdleNotifier],
  _getActiveRequests: [Function: _getActiveRequests],
  _getActiveHandles: [Function: _getActiveHandles],
  reallyExit: [Function: reallyExit],
  abort: [Function: abort],
  chdir: [Function: chdir],
  cwd: [Function: cwd],
  umask: [Function: umask],
  _kill: [Function: _kill],
  _debugProcess: [Function: _debugProcess],
  _debugPause: [Function: _debugPause],
  _debugEnd: [Function: _debugEnd],
  hrtime: [Function: hrtime],
  cpuUsage: [Function: cpuUsage],
  dlopen: [Function: dlopen],
  uptime: [Function: uptime],
  memoryUsage: [Function: memoryUsage],
  binding: [Function: binding],
  _linkedBinding: [Function: _linkedBinding],
  _events:
   { warning: [Function],
     newListener: [Function],
     removeListener: [Function],
     SIGWINCH: [ [Function], [Function] ] },
  _rawDebug: [Function],
  _eventsCount: 4,
  domain: [Getter/Setter],
  _maxListeners: undefined,
  _fatalException: [Function],
  _exiting: false,
  assert: [Function],
  config:
   { target_defaults:
      { cflags: [],
        default_configuration: 'Release',
        defines: [],
        include_dirs: [],
        libraries: [] },
     variables:
      { asan: 0,
        coverage: false,
        debug_devtools: 'node',
        force_dynamic_crt: 0,
        host_arch: 'x64',
        icu_data_file: 'icudt59l.dat',
        icu_data_in: '..\\..\\deps/icu-small\\source/data/in\\icudt59l.dat',
        icu_endianness: 'l',
        icu_gyp_path: 'tools/icu/icu-generic.gyp',
        icu_locales: 'en,root',
        icu_path: 'deps/icu-small',
        icu_small: true,
        icu_ver_major: '59',
        node_byteorder: 'little',
        node_enable_d8: false,
        node_enable_v8_vtunejit: false,
        node_install_npm: true,
        node_module_version: 57,
        node_no_browser_globals: false,
        node_prefix: '/usr/local',
        node_release_urlbase: 'https://nodejs.org/download/release/',
        node_shared: false,
        node_shared_cares: false,
        node_shared_http_parser: false,
        node_shared_libuv: false,
        node_shared_openssl: false,
        node_shared_zlib: false,
        node_tag: '',
        node_use_bundled_v8: true,
        node_use_dtrace: false,
        node_use_etw: true,
        node_use_lttng: false,
        node_use_openssl: true,
        node_use_perfctr: true,
        node_use_v8_platform: true,
        node_without_node_options: false,
        openssl_fips: '',
        openssl_no_asm: 0,
        shlib_suffix: 'so.57',
        target_arch: 'x64',
        v8_enable_gdbjit: 0,
        v8_enable_i18n_support: 1,
        v8_enable_inspector: 1,
        v8_no_strict_aliasing: 1,
        v8_optimized_debug: 0,
        v8_promise_internal_field_count: 1,
        v8_random_seed: 0,
        v8_use_snapshot: true,
        want_separate_host_toolset: 0,
        want_separate_host_toolset_mkpeephole: 0 } },
  emitWarning: [Function],
  nextTick: [Function: nextTick],
  _tickCallback: [Function: _tickDomainCallback],
  _tickDomainCallback: [Function: _tickDomainCallback],
  stdout: [Getter],
  stderr: [Getter],
  stdin: [Getter],
  openStdin: [Function],
  exit: [Function],
  kill: [Function],
  argv0: 'node.exe' }
undefined
>

When I use chalk (or anything else that depends on this module), output is not colored by default and must be forced with CLI arguments.

Tried the test under Cygwin where I have at least 16 color palette, but this script fails, telling me otherwise.

$ supports-color --256
$ echo $?
1

I believe it's not possible looking at the code, but it would be great if you could force 256 colors like this:

FORCE_COLOR=256 prism.js -f prism.js -l javascript | less -R

https://github.com/chalk/supports-color/blob/master/index.js#L22

Could you provide a little context on why color should be disabled if it isn't TTY? Seems like it should be the other way around, or maybe I'm not understanding...

Hey there Sindre, hope you're doing well 😄

I was just wondering why a win32 platform returns true in this library?

    if (process.platform === 'win32') {
        return true;
    }

The Chalk library and its dependencies all seem to only support Linux as far as I can see.

Can you possibly clarify this?

Thanks heaps! 😄
Fotis

forceColor should be declared as var, otherwise using UglifyJs will be wrong

Unexpected token: name (forceColor) [./node_modules/supports-color/index.js:7,0]

I'm currently working on a package where I'm planning on switching to chalk and up to now TravisCI didn't have any problems with colours on the console (using colors) but after pushing some code with passing tests (on the chalk-based codebase), Travis seems to disable colours which make all the tests fail.

I've understood from this comment that TravisCI seems to non-determistically change supports-color but I'm unsure if there's a fix for that or if I have to manually enable it using chalk.enable = true or even set the chalk.level to something other than 0 (which is what I get on the TravisCI log).

EDIT: if (!chalk.enabled) chalk.enabled = true; doesn't help.

I see that the code checks for 'xterm' and 'linux' explicitly, but 'screen' should be part of this list, I think. Either that or there must be some way to tell if screen is running with color support.

Systemd's journalctl takes a process's stdout/stderr and has it's own log levels which colors lines, but if the -o cat switch is used, it is able to display colors, but this case doesn't seem to be detected correctly.

I have no idea yet how this specific case could be detected, though.

Why does node running in a TTY context makes has-color grumpy ?

If I run

node -p -e "Boolean(process.stdout.isTTY)" 

in my fish shell, it will returns true. So has-color returns false.
I know that fish supports colours.

Did I miss some understanding ?

If one of the maintainers has a moment, the interwebs would greatly appreciate an update to the Releases for the project. It looks as though 9 releases have gone by without an update. 🙇

Should we detect screen-256color and return level 2 color support?

http://superuser.com/questions/424086/what-is-the-difference-between-screen-256-color-and-xterm-256color

Found it here: https://github.com/junegunn/fzf#rendering-issues

// @Qix-

Right now we have a blanket clause for win32 to disable colors; this is no longer the case on windows.

@sindresorhus you'll have a better idea as to how to properly detect the correct version of windows. Thoughts?

Currently FORCE_COLOR is used to force color support. It would be great if we can agree upon some sort of standard for the name of this environment variable as many tools need something like this (e.g. compilers, build tools, ...) written in lots of different languages.

As this really bugs me (working with Jenkins and atom-build and still not seeing colored output even though it would work), I've written a page about it here: http://bixense.com/clicolors/

What do you think? With CLICOLOR=0 this would also fix #31.

Hi,

i tried using the new 1.3.0 version but the color detection is not working correctly. Iam using ubuntu 14.10

For me

if ('UPSTART_JOB' in process.env) {
    return false;
}

is always true.

however i tested ('UPSTART_JOB' in process.env) ? true : false; on different systems

so for debian it works correctly.

i switched back to version 1.2.1 for now as it works for me.

In worker threads, supports-color is unable to automatically detect color support.

const { Worker, isMainThread } = require('worker_threads')
const supportsColor = require('supports-color')

if (isMainThread) {
  console.log('mainThread, supportsColor.stdout', supportsColor.stdout)
  console.log('mainThread, supportsColor.stderr', supportsColor.stderr)
  new Worker(__filename)
} else {
  console.log('workerThread, supportsColor.stdout', supportsColor.stdout)
  console.log('workerThread, supportsColor.stderr', supportsColor.stderr)
}

$ node ./main.js 
mainThread, supportsColor.stdout { level: 2, hasBasic: true, has256: true, has16m: false }
mainThread, supportsColor.stderr { level: 2, hasBasic: true, has256: true, has16m: false }
workerThread, supportsColor.stdout false
workerThread, supportsColor.stderr false

It looks like the stream type in worker threads is WritableWorkerStdio which returns isTTY false so the check at:

It looks like env.CI will suppress color, which is probably the right choice for most CI servers, but travis-ci should perhaps get a pass, since it handles terminal colors quite nicely.

Would you be open to allowing color if env.TRAVIS is set?