@rushstack/terminal is a library designed to provide a standardized way to handle terminal output in Node.js applications. It offers features for writing colored text, handling different log levels, and managing output streams in a consistent manner.

What are @rushstack/terminal's main functionalities?

Colored Text Output

This feature allows you to write colored text to the terminal. The `formatColor` method is used to apply color to the text.

const { Terminal } = require('@rushstack/terminal');
const terminal = new Terminal(process.stdout);
terminal.writeLine('This is a normal line.');
terminal.writeLine(terminal.formatColor('red', 'This is a red line.'));
terminal.writeLine(terminal.formatColor('green', 'This is a green line.'));

Log Levels

This feature allows you to write messages with different log levels such as verbose, warning, and error. This helps in categorizing the output based on its importance.

const { Terminal, ConsoleTerminalProvider } = require('@rushstack/terminal');
const terminalProvider = new ConsoleTerminalProvider();
const terminal = new Terminal(terminalProvider);
terminal.writeVerboseLine('This is a verbose message.');
terminal.writeWarningLine('This is a warning message.');
terminal.writeErrorLine('This is an error message.');

Output Streams

This feature allows you to manage output streams. In this example, the output is written to a string buffer instead of directly to the console, which can be useful for testing or logging purposes.

const { Terminal, StringBufferTerminalProvider } = require('@rushstack/terminal');
const stringBuffer = new StringBufferTerminalProvider();
const terminal = new Terminal(stringBuffer);
terminal.writeLine('This is a line in the buffer.');
console.log(stringBuffer.getOutput());

Other packages similar to @rushstack/terminal

Readme

Source

@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, 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 - Find out what's new in the latest version
API Reference

@rushstack/terminal is part of the Rush Stack family of projects.

FAQs

What is @rushstack/terminal?

Is @rushstack/terminal well maintained?

Last updated on 24 Feb 2024

Did you know?

Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.

Install