process.stdout/stderr.isTTY undefined in worker_thread

Version: v11.12.0
Platform: macOS Mojave 10.14.4 (Darwin brewster.local 18.5.0 Darwin Kernel Version 18.5.0: Mon Mar 11 20:40:32 PDT 2019; root:xnu-4903.251.3~3/RELEASE_X86_64 x86_64)
Subsystem: worker_threads

In worker threads, process.stdout.isTTY and process.stderr.isTTY are undefined.

const { Worker, isMainThread } = require('worker_threads')
if (isMainThread) {
  console.log('mainThread, process.stdout.isTTY', process.stdout.isTTY)
  console.log('mainThread, process.stderr.isTTY', process.stderr.isTTY)
  new Worker(__filename)
} else {
  console.log('workerThread, process.stdout.isTTY', process.stdout.isTTY)
  console.log('workerThread, process.stderr.isTTY', process.stderr.isTTY)
}

$ node ./main.js 
mainThread, process.stdout.isTTY true
mainThread, process.stderr.isTTY true
workerThread, process.stdout.isTTY undefined
workerThread, process.stderr.isTTY undefined

I am not sure if this is intended behavior or not, but I found it while looking into why supports-color reports that color is not supported from worker threads (see chalk/supports-color#97). If I ignore the isTTY flag, then color output does seem to work correctly.

@addaleax

// cc @addaleax

IMO it make sense for .isTTY to be undefined because process.stdout and process.stderr in worker threads don't actually write to the TTY. They postMessage() the data to the main thread which then writes it out on the worker thread's behalf.

We could copy the .isTTY values from the main thread but that breaks the idiom where if (process.stdout.isTTY) guards are used around calls to process.stdout.setRawMode(true) or process.stdout.cursorTo() - and you can't reasonably support those APIs in worker threads because the TTY is a per-process resource.

Same also applies to child processes, fwiw: #2333.

@silverwind

@silverwind For child_process (cluster and fork) it is possible to pass current process stdio using the third argument ({ stdout: process.stdout }) and it preserves isTTY but for threads, we can't.

As a (temporary) workaround, we can set workerData: { isTTY: process.stdout.isTTY }, when creating Worker and in very beginning of worker script:

const { workerData } = require('worker_threads')

if (workerData.isTTY) {
  for (const stream of ['stdout', 'stdin', 'stderr']) {
    if (process[stream].isTTY === undefined) {
      process[stream].isTTY = true
    }
  }
}

I'm going to close this out. It's working as expected as far as I'm concerned and 343ddff adds hints to the documentation.

@bnoordhuis

We could copy the .isTTY values from the main thread but that breaks the idiom where if (process.stdout.isTTY) guards are used around calls to process.stdout.setRawMode(true) or process.stdout.cursorTo()

@bnoordhuis It would be useful to be able to know whether the main thread is TTY though. When you know you don't need things that are unsupported. For example, it could be useful to decide whether to print ANSI colors from the worker thread. Could Node.js somehow expose to the worker thread whether stdout/stderr in the main thread is TTY?

IMHO process.stdout.isTTY should never be undefined but simply false.

Fix colorize error when stderr isn't TTY

Navigation Menu

Repository navigation

process.stdout/stderr.isTTY undefined in worker_thread #26946

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

process.stdout/stderr.isTTY undefined in worker_thread #26946

Description

Activity

BridgeAR commented on Mar 27, 2019

bnoordhuis commented on Mar 28, 2019

silverwind commented on Apr 10, 2019

pi0 commented on May 7, 2019

bnoordhuis commented on Jan 21, 2020

sindresorhus commented on Nov 24, 2020

LinqLover commented on Jan 24, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions