https://github.com/sindresorhus/is-interactive

Check if stdout or stderr is interactive
https://github.com/sindresorhus/is-interactive

interactive-shell nodejs npm-package stdout stdout-stream terminal tty

Last synced: 7 days ago
JSON representation

Check if stdout or stderr is interactive

• Host: GitHub
• URL: https://github.com/sindresorhus/is-interactive
• Owner: sindresorhus
• License: mit
• Created: 2019-07-06T16:02:46.000Z (over 5 years ago)
• Default Branch: main
• Last Pushed: 2023-11-06T21:14:27.000Z (about 1 year ago)
• Last Synced: 2024-10-29T13:04:28.131Z (about 2 months ago)
• Topics: interactive-shell, nodejs, npm-package, stdout, stdout-stream, terminal, tty
• Language: JavaScript
• Homepage:
• Size: 9.77 KB
• Stars: 115
• Watchers: 3
• Forks: 5
• Open Issues: 0
• Metadata Files:
  • Readme: readme.md
  • License: license
  • Security: .github/security.md

Awesome Lists containing this project

• awesome - sindresorhus/is-interactive - Check if stdout or stderr is interactive (terminal)

README

        
# is-interactive

> Check if stdout or stderr is [interactive](https://unix.stackexchange.com/a/43389/7678)

It checks that the stream is [TTY](https://jameshfisher.com/2017/12/09/what-is-a-tty/), not a dumb terminal, and not running in a CI.

This can be useful to decide whether to present interactive UI or animations in the terminal.

## Install

```sh

npm install is-interactive

```

## Usage

```js

import isInteractive from 'is-interactive';

isInteractive();

//=> true

```

## API

### isInteractive(options?)

#### options

Type: `object`

##### stream

Type: [`stream.Writable`](https://nodejs.org/api/stream.html#stream_class_stream_writable)\

Default: [`process.stdout`](https://nodejs.org/api/process.html#process_process_stdout)

The stream to check.

## FAQ

#### Why are you not using [`ci-info`](https://github.com/watson/ci-info) for the CI check?

It's silly to have to detect individual CIs. They should identify themselves with the `CI` environment variable, and most do just that. A manually maintained list of detections will easily get out of date. And if a package using `ci-info` doesn't update to the latest version all the time, they will not support certain CIs. It also creates unpredictability as you might assume a CI is not supported and then suddenly it gets supported and you didn't account for that. In addition, some of the manual detections are loose and might cause false-positives which could create hard-to-debug bugs.

#### Why does this even exist? It's just a few lines.

It's not about the number of lines, but rather discoverability and documentation. A lot of people wouldn't even know they need this. Feel free to copy-paste the code if you don't want the dependency. You might also want to read [this blog post](https://sindresorhus.com/blog/small-focused-modules).

## Related

- [is-in-ci](https://github.com/sindresorhus/is-in-ci) - Check if the process is running in a Continuous Integration (CI) environment

- [is-unicode-supported](https://github.com/sindresorhus/is-unicode-supported) - Detect whether the terminal supports Unicode

- [supports-color](https://github.com/chalk/supports-color) - Detect whether a terminal supports color