@rushstack/terminal 0.3.67 → 0.3.68

package/dist/tsdoc-metadata.json

@@ -5,7 +5,7 @@
   "toolPackages": [
     {
       "packageName": "@microsoft/api-extractor",
-      "packageVersion": "7.29.4"
+      "packageVersion": "7.29.5"
     }
   ]
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rushstack/terminal",
-  "version": "0.3.67",
+  "version": "0.3.68",
   "description": "User interface primitives for console applications",
   "main": "lib/index.js",
   "typings": "dist/terminal.d.ts",
@@ -18,7 +18,7 @@
   "devDependencies": {
     "@rushstack/eslint-config": "3.0.0",
     "@rushstack/heft": "0.47.5",
-    "@rushstack/heft-node-rig": "1.10.5",
+    "@rushstack/heft-node-rig": "1.10.6",
     "@types/heft-jest": "1.0.1",
     "@types/wordwrap": "~1.0.0",
     "colors": "~1.2.1"
@@ -27,6 +27,5 @@
     "build": "heft build --clean",
     "_phase:build": "heft build --clean",
     "_phase:test": "heft test --no-build"
-  },
-  "readme": "# @rushstack/terminal\n\nThis library implements a system for processing human readable text that\nwill be output by console applications.\n\nThe design is based loosely on the `WritableStream` and `TransformStream` classes from\nthe system [Streams API](https://developer.mozilla.org/en-US/docs/Web/API/Streams_API/Concepts),\nexcept that instead of asynchronous byte streams, the `TerminalWritable` system synchronously transmits\nhuman readable messages intended to be rendered on a text console or log file.\n\nConsider a console application whose output may need to be processed in different ways\nbefore finally being output. The conceptual block diagram might look like this:\n\n```\n         [Terminal API]\n                |\n                V\n       [normalize newlines]\n                |\n                V\n      +----[splitter]-------+\n      |                     |\n      V                     V\n  [shell console]     [remove ANSI colors]\n                            |\n                            V\n                      [write to build.log]\n```\n\nThe application uses the `Terminal` API to print `stdout` and `stderr` messages, for example with standardized\nformatting for errors and warnings, and ANSI escapes to make nice colors. Maybe it also includes text\nreceived from external processes, whose newlines may be inconsistent. Ultimately we want to write the\noutput to the shell console and a `build.log` file, but we don't want to put ANSI colors in the build log.\n\nFor the above example, `[shell console]` and `[write to build.log]` would be modeled as subclasses of\n`TerminalWritable`. The `[normalize newlines]` and `[remove ANSI colors]` steps are modeled as subclasses\nof `TerminalTransform`, because they output to a \"destination\" object. The `[splitter]` would be\nimplemented using `SplitterTransform`.\n\nThe stream of messages are {@link ITerminalChunk} objects, which can represent both `stdout` and `stderr`\nchannels. The pipeline operates synchronously on each chunk, but by processing one chunk at a time,\nit avoids storing the entire output in memory. This means that operations like `[remove ANSI colors]`\ncannot be simple regular expressions -- they must be implemented as state machines (`TextRewriter` subclasses)\ncapable of matching substrings that span multiple chunks.\n\n## Links\n\n- [CHANGELOG.md](\n  https://github.com/microsoft/rushstack/blob/main/libraries/terminal/CHANGELOG.md) - Find\n  out what's new in the latest version\n- [API Reference](https://rushstack.io/pages/api/terminal/)\n\n`@rushstack/terminal` is part of the [Rush Stack](https://rushstack.io/) family of projects.\n"
+  }
 }