# @rushstack/terminal

> User interface primitives for console applications

Latest version **0.24.4** (published 2026-09-09) · MIT license · 0 weekly downloads

## Install

```sh
npm install @rushstack/terminal
pnpm add @rushstack/terminal
yarn add @rushstack/terminal
bun add @rushstack/terminal
```

## Health

**Score 65/100 (B)** — status: active.

Positive: has types; esm support; no vulnerabilities; recently updated; high maintenance score.

Warnings: low downloads; pre 1.0.

## Facts

| | |
|---|---|
| Version | 0.24.4 |
| Published | 2026-09-09 |
| First published | 2020-09-11 |
| Weekly downloads | 0 |
| License | MIT |
| TypeScript types | bundled |
| Module format | ESM + CommonJS |
| Node | >=20.9.0 |
| Dependencies | 3 |
| Unpacked size | 844.8 KB |
| Known vulnerabilities | 0 |
| Install scripts | no |
| GitHub stars | 6496 |
| Maintainers | rushstack-admin, odspnpm, octogonz, microsoft1es |

## Links

- npm: https://www.npmjs.com/package/@rushstack/terminal
- Repository: https://github.com/microsoft/rushstack
- Homepage: https://github.com/microsoft/rushstack#readme
- Issues: https://github.com/microsoft/rushstack/issues
- npm.io page: https://npm.io/package/@rushstack/terminal

## Dependencies (3)

- [supports-color](https://npm.io/package/supports-color.md) ~8.1.1
- [@rushstack/problem-matcher](https://npm.io/package/@rushstack/problem-matcher.md) 0.2.1
- [@rushstack/node-core-library](https://npm.io/package/@rushstack/node-core-library.md) 5.24.1

## Recent versions

- 0.24.4 (latest) — 2026-09-09
- 0.21.0 (pr5496) — 2026-01-12
- 0.24.3 — 2026-08-20
- 0.24.2 — 2026-07-17
- 0.24.1 — 2026-07-16
- 0.24.0 — 2026-04-20
- 0.23.0 — 2026-04-18
- 0.22.7 — 2026-04-18
- 0.22.6 — 2026-04-17
- 0.22.5 — 2026-04-09
- 0.22.4 — 2026-03-31
- 0.22.3 — 2026-02-25
- 0.22.2 — 2026-02-24
- 0.22.1 — 2026-02-20
- 0.22.0 — 2026-02-19
- … 330 more at https://npm.io/package/@rushstack/terminal/versions

## README

# @rushstack/terminal

This library implements a system for processing human readable text that
will be output by console applications.

The design is based loosely on the `WritableStream` and `TransformStream` classes from
the system [Streams API](https://developer.mozilla.org/en-US/docs/Web/API/Streams_API/Concepts),
except that instead of asynchronous byte streams, the `TerminalWritable` system synchronously transmits
human readable messages intended to be rendered on a text console or log file.

Consider a console application whose output may need to be processed in different ways
before finally being output. The conceptual block diagram might look like this:

```
         [Terminal API]
                |
                V
       [normalize newlines]
                |
                V
      +----[splitter]-------+
      |                     |
      V                     V
  [shell console]     [remove ANSI colors]
                            |
                            V
                      [write to build.log]
```

The application uses the `Terminal` API to print `stdout` and `stderr` messages, for example with standardized
formatting for errors and warnings, and ANSI escapes to make nice colors. Maybe it also includes text
received from external processes, whose newlines may be inconsistent. Ultimately we want to write the
output to the shell console and a `build.log` file, but we don't want to put ANSI colors in the build log.

For the above example, `[shell console]` and `[write to build.log]` would be modeled as subclasses of
`TerminalWritable`. The `[normalize newlines]` and `[remove ANSI colors]` steps are modeled as subclasses
of `TerminalTransform`, because they output to a "destination" object. The `[splitter]` would be
implemented using `SplitterTransform`.

The stream of messages are {@link ITerminalChunk} objects, which can represent both `stdout` and `stderr`
channels. The pipeline operates synchronously on each chunk, but by processing one chunk at a time,
it avoids storing the entire output in memory. This means that operations like `[remove ANSI colors]`
cannot be simple regular expressions -- they must be implemented as state machines (`TextRewriter` subclasses)
capable of matching substrings that span multiple chunks.

## Links

- [CHANGELOG.md](
  https://github.com/microsoft/rushstack/blob/main/libraries/terminal/CHANGELOG.md) - Find
  out what's new in the latest version
- [API Reference](https://api.rushstack.io/pages/terminal/)

`@rushstack/terminal` is part of the [Rush Stack](https://rushstack.io/) family of projects.

---
_Source: https://npm.io/package/@rushstack/terminal · Machine-readable twin of the npm.io package page. Health data is recomputed on every publish._