Docs and types for v0.8.0 (#4199)

* Improve test documentation

* Update nodejs compat docs with tty

* Add debugger guide

* Document Bun.inspect.custom, improve bun test nav

* Address reviews

* Update Bun.file types

* Add Nuxt guide

* Add tty types

10 files changed, 487 insertions, 37 deletions

diff --git a/docs/api/utils.md b/docs/api/utils.md
index 2723edf7c..8b166e3e8 100644
--- a/docs/api/utils.md
+++ b/docs/api/utils.md
@@ -428,6 +428,21 @@ const str = Bun.inspect(arr);
 // => "Uint8Array(3) [ 1, 2, 3 ]"
 ```
 
+## `Bun.inspect.custom`
+
+This is the symbol that Bun uses to implement `Bun.inspect`. You can override this to customize how your objects are printed. It is identical to `util.inspect.custom` in Node.js.
+
+```ts
+class Foo {
+  [Bun.inspect.custom]() {
+    return "foo";
+  }
+}
+
+const foo = new Foo();
+console.log(foo); // => "foo"
+```
+
 ## `Bun.nanoseconds()`
 
 Returns the number of nanoseconds since the current `bun` process started, as a `number`. Useful for high-precision timing and benchmarking.
diff --git a/docs/cli/test.md b/docs/cli/test.md
index 209685042..dfe78c45b 100644
--- a/docs/cli/test.md
+++ b/docs/cli/test.md
@@ -30,14 +30,50 @@ The runner recursively searches the working directory for files that match the f
 - `*.spec.{js|jsx|ts|tsx}`
 - `*_spec.{js|jsx|ts|tsx}`
 
-You can filter the set of tests to run by passing additional positional arguments to `bun test`. Any file in the directory with an _absolute path_ that contains one of the filters will run. Commonly, these filters will be file or directory names; glob patterns are not yet supported.
+You can filter the set of _test files_ to run by passing additional positional arguments to `bun test`. Any test file with a path that matches one of the filters will run. Commonly, these filters will be file or directory names; glob patterns are not yet supported.
 
 ```bash
 $ bun test <filter> <filter> ...
 ```
 
+To filter by _test name_, use the `-t`/`--test-name-pattern` flag.
+
+```sh
+# run all tests or test suites with "addition" in the name
+$ bun test --test-name-pattern addition
+```
+
 The test runner runs all tests in a single process. It loads all `--preload` scripts (see [Lifecycle](/docs/test/lifecycle) for details), then runs all tests. If a test fails, the test runner will exit with a non-zero exit code.
 
+## Timeouts
+
+Use the `--timeout` flag to specify a _per-test_ timeout in milliseconds. If a test times out, it will be marked as failed. The default value is `5000`.
+
+```bash
+# default value is 5000
+$ bun test --timeout 20
+```
+
+## Rerun tests
+
+Use the `--rerun-each` flag to run each test multiple times. This is useful for detecting flaky or non-deterministic test failures.
+
+```sh
+$ bun test --rerun-each 100
+```
+
+## Bail out with `--bail`
+
+Use the `--bail` flag to abort the test run early after a pre-determined number of test failures. By default Bun will run all tests and report all failures, but sometimes in CI environments it's preferable to terminate earlier to reduce CPU usage.
+
+```sh
+# bail after 1 failure
+$ bun test --bail
+
+# bail after 10 failure
+$ bun test --bail 10
+```
+
 ## Watch mode
 
 Similar to `bun run`, you can pass the `--watch` flag to `bun test` to watch for changes and re-run tests.
diff --git a/docs/guides/ecosystem/nuxt.md b/docs/guides/ecosystem/nuxt.md
new file mode 100644
index 000000000..bb0291754
--- /dev/null
+++ b/docs/guides/ecosystem/nuxt.md
@@ -0,0 +1,65 @@
+---
+name: Build an app with Nuxt and Bun
+---
+
+Bun supports [Nuxt](https://nuxt.com) out of the box. Initialize a Nuxt app with official `nuxi` CLI.
+
+```sh
+$ bunx nuxi init my-nuxt-app
+Nuxi 3.6.5
+✨ Nuxt project is created with v3 template. Next steps:
+ › cd my-nuxt-app
+ › Install dependencies with npm install or yarn install or pnpm install
+ › Start development server with npm run dev or yarn dev or pnpm run dev
+```
+
+---
+
+Then move into the project directory and install dependencies.
+
+```sh
+$ cd my-app
+$ bun install
+bun install v0.8.0
+ + @nuxt/devtools@0.8.0
+ + @types/node@18.17.6
+ + nuxt@3.6.5
+Nuxi 3.6.5
+✔ Types generated in .nuxt
+
+ 776 packages installed [1.72s]
+```
+
+---
+
+To start the dev server, run `bun run dev` from the project root. This will execute the `nuxt dev` command (as defined in the `"dev"` script in `package.json`).
+
+{% callout %}
+The `nuxt` CLI uses Node.js by default; passing the `--bun` flag forces the dev server to use the Bun runtime instead.
+{% /callout %}
+
+```
+$ bun --bun run dev
+ $ nuxt dev
+Nuxi 3.6.5
+Nuxt 3.6.5 with Nitro 2.5.2
+  > Local:    http://localhost:3000/
+  > Network:  http://192.168.0.21:3000/
+  > Network:  http://[fd8a:d31d:481c:4883:1c64:3d90:9f83:d8a2]:3000/
+
+✔ Nuxt DevTools is enabled v0.8.0 (experimental)
+ℹ Vite client warmed up in 547ms
+✔ Nitro built in 244 ms
+```
+
+---
+
+Once the dev server spins up, open [http://localhost:3000](http://localhost:3000) to see the app. The app will render Nuxt's built-in `WelcomePage` template component.
+
+To start developing your app, replace `<WelcomePage />` in `app.vue` with your own UI.
+
+{% image src="https://github.com/oven-sh/bun/assets/3084745/2c683ecc-3298-4bb0-b8c0-cf4cfaea1daa" caption="Demo Nuxt app running on localhost" /%}
+
+---
+
+Refer to the [Nuxt website](https://nuxt.com/docs) for complete documentation.
diff --git a/docs/guides/runtime/web-debugger.md b/docs/guides/runtime/web-debugger.md
new file mode 100644
index 000000000..d41d93b4a
--- /dev/null
+++ b/docs/guides/runtime/web-debugger.md
@@ -0,0 +1,82 @@
+---
+name: Debugging Bun with the web debugger
+---
+
+Bun speaks the [WebKit Inspector Protocol](https://github.com/oven-sh/bun/blob/main/packages/bun-vscode/types/jsc.d.ts). To enable debugging when running code with Bun, use the `--inspect` flag. For demonstration purposes, consider the following simple web server.
+
+```ts#server.ts
+Bun.serve({
+  fetch(req){
+    console.log(req.url);
+    return new Response("Hello, world!");
+  }
+})
+```
+
+---
+
+Let's run this file with the `--inspect` flag.
+
+This automatically starts a WebSocket server on an available port that can be used to introspect the running Bun process. Various debugging tools can connect to this server to provide an interactive debugging experience.
+
+Bun hosts a web-based debugger at [debug.bun.sh](https://debug.bun.sh). It is a modified version of WebKit's [Web Inspector Interface](https://webkit.org/web-inspector/web-inspector-interface/), which will look familiar to Safari users.
+
+```sh
+$ bun --inspect server.ts
+------------------ Bun Inspector ------------------
+Listening at:
+  ws://localhost:6499/0tqxs9exrgrm
+
+Inspect in browser:
+  https://debug.bun.sh/#localhost:6499/0tqxs9exrgrm
+------------------ Bun Inspector ------------------
+```
+
+---
+
+Open the provided `debug.bun.sh` URL in your browser to start a debugging session. From this interface, you'll be able to view the source code of the running file, view and set breakpoints, and execute code with the built-in console.
+
+{% image src="https://github.com/oven-sh/bun/assets/3084745/e6a976a8-80cc-4394-8925-539025cc025d" alt="Screenshot of Bun debugger, Console tab" /%}
+
+---
+
+Let's set a breakpoint. Navigate to the Sources tab; you should see the code from earlier. Click on the line number `3` to set a breakpoint on our `console.log(req.url)` statement.
+
+{% image src="https://github.com/oven-sh/bun/assets/3084745/3b69c7e9-25ff-4f9d-acc4-caa736862935" alt="screenshot of Bun debugger" /%}
+
+---
+
+Then visit [`http://localhost:3000`](http://localhost:3000) in your web browser. This will send an HTTP request to our `localhost` web server. It will seem like the page isn't loading. Why? Because the program has paused execution at the breakpoint we set earlier.
+
+Note how the UI has changed.
+
+{% image src="https://github.com/oven-sh/bun/assets/3084745/8b565e58-5445-4061-9bc4-f41090dfe769" alt="screenshot of Bun debugger" /%}
+
+---
+
+At this point there's a lot we can do to introspect the current execution environment. We can use the console at the bottom to run arbitrary code in the context of the program, with full access to the variables in scope at our breakpoint.
+
+{% image src="https://github.com/oven-sh/bun/assets/3084745/f4312b76-48ba-4a7d-b3b6-6205968ac681" /%}
+
+---
+
+On the right side of the Sources pane, we can see all local variables currently in scope, and drill down to see their properties and methods. Here, we're inspecting the `req` variable.
+
+{% image src="https://github.com/oven-sh/bun/assets/3084745/63d7f843-5180-489c-aa94-87c486e68646" /%}
+
+---
+
+In the upper left of the Sources pane, we can control the execution of the program.
+
+{% image src="https://github.com/oven-sh/bun/assets/3084745/41b76deb-7371-4461-9d5d-81b5a6d2f7a4" /%}
+
+---
+
+Here's a cheat sheet explaining the functions of the control flow buttons.
+
+- _Continue script execution_ — continue running the program until the next breakpoint or exception.
+- _Step over_ — The program will continue to the next line.
+- _Step into_ — If the current statement contains a function call, the debugger will "step into" the called function.
+- _Step out_ — If the current statement is a function call, the debugger will finish executing the call, then "step out" of the function to the location where it was called.
+
+{% image src="https://github-production-user-asset-6210df.s3.amazonaws.com/3084745/261510346-6a94441c-75d3-413a-99a7-efa62365f83d.png" /%}
diff --git a/docs/nav.ts b/docs/nav.ts
index 4f12507f4..e54a89552 100644
--- a/docs/nav.ts
+++ b/docs/nav.ts
@@ -188,13 +188,13 @@ export default {
     page("cli/test", "`bun test`", {
       description: "Bun's test runner uses Jest-compatible syntax but runs 100x faster.",
     }),
-    page("test/hot", "Watch mode", {
-      description: "Reload your tests automatically on change.",
-    }),
     page("test/writing", "Writing tests", {
       description:
         "Write your tests using Jest-like expect matchers, plus setup/teardown hooks, snapshot testing, and more",
     }),
+    page("test/hot", "Watch mode", {
+      description: "Reload your tests automatically on change.",
+    }),
     page("test/lifecycle", "Lifecycle hooks", {
       description: "Add lifecycle hooks to your tests that run before/after each test or test run",
     }),
diff --git a/docs/runtime/nodejs-apis.md b/docs/runtime/nodejs-apis.md
index b75ff5847..e0cd3b132 100644
--- a/docs/runtime/nodejs-apis.md
+++ b/docs/runtime/nodejs-apis.md
@@ -138,7 +138,7 @@ This page is updated regularly to reflect compatibility status of the latest ver
 
 ### [`node:tty`](https://nodejs.org/api/tty.html)
 
-🟡 Missing `tty.ReadStream` and `tty.WriteStream`.
+🟢 Fully implemented.
 
 ### [`node:url`](https://nodejs.org/api/url.html)
 
diff --git a/docs/test/coverage.md b/docs/test/coverage.md
index 229da41f2..503b5abf6 100644
--- a/docs/test/coverage.md
+++ b/docs/test/coverage.md
@@ -1,12 +1,11 @@
-`bun:test` supports seeing which lines of code are covered by tests. To use this feature, pass `--coverage` to the CLI:
+Bun's test runner now supports built-in _code coverage reporting_. This makes it easy to see how much of the codebase is covered by tests, and find areas that are not currently well-tested.
 
-```sh
-bun test --coverage
-```
+## Enabling coverage
 
-It will print out a coverage report to the console:
+`bun:test` supports seeing which lines of code are covered by tests. To use this feature, pass `--coverage` to the CLI. It will print out a coverage report to the console:
 
 ```js
+$ bun test --coverage
 -------------|---------|---------|-------------------
 File         | % Funcs | % Lines | Uncovered Line #s
 -------------|---------|---------|-------------------
@@ -26,32 +25,45 @@ All files    |   38.89 |   42.11 |
 -------------|---------|---------|-------------------
 ```
 
-If coverage is below a threshold, `bun:test` will exit with a non-zero exit code to indicate the failure.
+To always enable coverage reporting by default, add the following line to your `bunfig.toml`:
 
-### Configuring coverage
+```toml
+[test]
 
-`bunfig.toml` supports configuring coverage:
+# always enable coverage
+coverage = true
+```
+
+By default coverage reports will _include_ test files and _exclude_ sourcemaps. This is usually what you want, but it can be configured otherwise in `bunfig.toml`.
 
 ```toml
 [test]
+coverageSkipTestFiles = true       # default false
+```
 
-# Always enable coverage
-coverage = true
+### Coverage thresholds
 
-# Anything less than 90% coverage will fail the test
-# coverageThreshold = 0.9
-coverageThreshold = { line = 0.9, function = 0.9 }
+{% callout %}
+**Note** — Support for coverage reporting was added in Bun v0.7.3.
+{% /callout %}
 
+It is possible to specify a coverage threshold in `bunfig.toml`. If your test suite does not meet or exceed this threshold, `bun test` will exit with a non-zero exit code to indicate the failure.
 
-# Don't include .test.* files in coverage reports
-coverageSkipTestFiles = true
+```toml
+[test]
 
-# Disable sourcemap support in coverage reports
-# By default, coverage reports will automatically use Bun's internal sourcemap.
-# You probably don't want to configure this
-# coverageIgnoreSourcemaps = false
+# to require 90% line-level and function-level coverage
+coverageThreshold = 0.9
+
+# to set different thresholds for lines and functions
+coverageThreshold = { line = 0.9, function = 0.9 }
 ```
 
-`coverageThreshold` can be either a number or an object with `line` and `function` keys. When a number, it is treated as both the line and function threshold.
+### Sourcemaps
 
-Coverage support was added in Bun v0.7.3.
+Internally, Bun transpiles all files by default, so Bun automatically generates an internal [source map](https://web.dev/source-maps/) that maps lines of your original source code onto Bun's internal representation. If for any reason you want to disable this, set `test.coverageIgnoreSourcemaps` to `false`; this will rarely be desirable outside of advanced use cases.
+
+```toml
+[test]
+coverageIgnoreSourcemaps = true   # default false
+```
diff --git a/packages/bun-types/globals.d.ts b/packages/bun-types/globals.d.ts
index 740cc9690..2d57b710f 100644
--- a/packages/bun-types/globals.d.ts
+++ b/packages/bun-types/globals.d.ts
@@ -602,9 +602,9 @@ interface Process {
   getgroups: () => number[];
   // setgroups?: (groups: ReadonlyArray<string | number>) => void;
   dlopen(module: { exports: any }, filename: string, flags?: number): void;
-  stdin: import("stream").Duplex & { isTTY: boolean };
-  stdout: import("stream").Writable & { isTTY: boolean };
-  stderr: import("stream").Writable & { isTTY: boolean };
+  stdin: import("tty").ReadStream;
+  stdout: import("tty").WriteStream;
+  stderr: import("tty").WriteStream;
 
   /**
    *
@@ -739,11 +739,10 @@ interface BlobInterface {
 
 type BlobPart = string | Blob | BufferSource;
 interface BlobPropertyBag {
-  /** Set a default "type" */
-  type?: string;
-
+  /** Set a default "type". Not yet implemented. */
+  // type?: string;
   /** Not implemented in Bun yet. */
-  endings?: "transparent" | "native";
+  // endings?: "transparent" | "native";
 }
 
 /**
diff --git a/packages/bun-types/tests/tty.test-d.ts b/packages/bun-types/tests/tty.test-d.ts
new file mode 100644
index 000000000..7e9f45115
--- /dev/null
+++ b/packages/bun-types/tests/tty.test-d.ts
@@ -0,0 +1,49 @@
+import * as tty from "tty";
+
+const rs = new tty.ReadStream(234, {
+  allowHalfOpen: true,
+  readable: true,
+  signal: new AbortSignal(),
+  writable: true,
+});
+
+const ws = new tty.WriteStream(234);
+
+process.stdin.setRawMode(true);
+process.stdin.setRawMode(false);
+process.stdin.isRaw;
+process.stdin.setRawMode(true).isRaw;
+
+rs.isRaw;
+rs.setRawMode(true);
+rs.setRawMode(false);
+rs.setRawMode(true).isRaw;
+rs.isTTY;
+
+ws.isPaused;
+ws.isTTY;
+ws.bytesWritten;
+ws.bytesRead;
+ws.columns;
+ws.rows;
+ws.isTTY;
+ws.clearLine(1);
+ws.clearLine(0);
+ws.clearScreenDown();
+ws.cursorTo(1);
+ws.cursorTo(1, 2);
+ws.cursorTo(1, () => {});
+ws.cursorTo(1, 2, () => {});
+ws.moveCursor(1, 2);
+ws.moveCursor(1, 2, () => {});
+ws.clearLine(1, () => {});
+ws.clearLine(0, () => {});
+ws.clearScreenDown(() => {});
+ws.cursorTo(1, () => {});
+
+process.stdout.clearLine;
+process.stdout.clearScreenDown;
+process.stdout.cursorTo;
+process.stdout.moveCursor;
+process.stdout.getColorDepth;
+process.stdout.getWindowSize;
diff --git a/packages/bun-types/tty.d.ts b/packages/bun-types/tty.d.ts
index 49f78fa2c..89e8d88b7 100644
--- a/packages/bun-types/tty.d.ts
+++ b/packages/bun-types/tty.d.ts
@@ -1,4 +1,31 @@
+/**
+ * The `tty` module provides the `tty.ReadStream` and `tty.WriteStream` classes.
+ * In most cases, it will not be necessary or possible to use this module directly.
+ * However, it can be accessed using:
+ *
+ * ```js
+ * const tty = require('tty');
+ * ```
+ *
+ * When Node.js detects that it is being run with a text terminal ("TTY")
+ * attached, `process.stdin` will, by default, be initialized as an instance of`tty.ReadStream` and both `process.stdout` and `process.stderr` will, by
+ * default, be instances of `tty.WriteStream`. The preferred method of determining
+ * whether Node.js is being run within a TTY context is to check that the value of
+ * the `process.stdout.isTTY` property is `true`:
+ *
+ * ```console
+ * $ node -p -e "Boolean(process.stdout.isTTY)"
+ * true
+ * $ node -p -e "Boolean(process.stdout.isTTY)" | cat
+ * false
+ * ```
+ *
+ * In most cases, there should be little to no reason for an application to
+ * manually create instances of the `tty.ReadStream` and `tty.WriteStream`classes.
+ * @see [source](https://github.com/nodejs/node/blob/v18.0.0/lib/tty.js)
+ */
 declare module "tty" {
+  import * as net from "node:net";
   /**
    * The `tty.isatty()` method returns `true` if the given `fd` is associated with
    * a TTY and `false` if it is not, including whenever `fd` is not a non-negative
@@ -7,10 +34,175 @@ declare module "tty" {
    * @param fd A numeric file descriptor
    */
   function isatty(fd: number): boolean;
-
-  // TODO: tty-browserify only polyfills functions that throws errors, wouldn't make sense to have types at the moment
-  var ReadStream: Function;
-  var WriteStream: Function;
+  /**
+   * Represents the readable side of a TTY. In normal circumstances `process.stdin` will be the only `tty.ReadStream` instance in a Node.js
+   * process and there should be no reason to create additional instances.
+   * @since v0.5.8
+   */
+  class ReadStream extends net.Socket {
+    constructor(fd: number, options?: net.SocketConstructorOpts);
+    /**
+     * A `boolean` that is `true` if the TTY is currently configured to operate as a
+     * raw device. Defaults to `false`.
+     * @since v0.7.7
+     */
+    isRaw: boolean;
+    /**
+     * Allows configuration of `tty.ReadStream` so that it operates as a raw device.
+     *
+     * When in raw mode, input is always available character-by-character, not
+     * including modifiers. Additionally, all special processing of characters by the
+     * terminal is disabled, including echoing input
+     * characters. Ctrl+C will no longer cause a `SIGINT` when
+     * in this mode.
+     * @since v0.7.7
+     * @param mode If `true`, configures the `tty.ReadStream` to operate as a raw device. If `false`, configures the `tty.ReadStream` to operate in its default mode. The `readStream.isRaw`
+     * property will be set to the resulting mode.
+     * @return The read stream instance.
+     */
+    setRawMode(mode: boolean): this;
+    /**
+     * A `boolean` that is always `true` for `tty.ReadStream` instances.
+     * @since v0.5.8
+     */
+    isTTY: boolean;
+  }
+  /**
+   * -1 - to the left from cursor
+   *  0 - the entire line
+   *  1 - to the right from cursor
+   */
+  type Direction = -1 | 0 | 1;
+  /**
+   * Represents the writable side of a TTY. In normal circumstances,`process.stdout` and `process.stderr` will be the only`tty.WriteStream` instances created for a Node.js process and there
+   * should be no reason to create additional instances.
+   * @since v0.5.8
+   */
+  class WriteStream extends net.Socket {
+    constructor(fd: number);
+    addListener(event: string, listener: (...args: any[]) => void): this;
+    addListener(event: "resize", listener: () => void): this;
+    emit(event: string | symbol, ...args: any[]): boolean;
+    emit(event: "resize"): boolean;
+    on(event: string, listener: (...args: any[]) => void): this;
+    on(event: "resize", listener: () => void): this;
+    once(event: string, listener: (...args: any[]) => void): this;
+    once(event: "resize", listener: () => void): this;
+    prependListener(event: string, listener: (...args: any[]) => void): this;
+    prependListener(event: "resize", listener: () => void): this;
+    prependOnceListener(
+      event: string,
+      listener: (...args: any[]) => void,
+    ): this;
+    prependOnceListener(event: "resize", listener: () => void): this;
+    /**
+     * `writeStream.clearLine()` clears the current line of this `WriteStream` in a
+     * direction identified by `dir`.
+     * @since v0.7.7
+     * @param callback Invoked once the operation completes.
+     * @return `false` if the stream wishes for the calling code to wait for the `'drain'` event to be emitted before continuing to write additional data; otherwise `true`.
+     */
+    clearLine(dir: Direction, callback?: () => void): boolean;
+    /**
+     * `writeStream.clearScreenDown()` clears this `WriteStream` from the current
+     * cursor down.
+     * @since v0.7.7
+     * @param callback Invoked once the operation completes.
+     * @return `false` if the stream wishes for the calling code to wait for the `'drain'` event to be emitted before continuing to write additional data; otherwise `true`.
+     */
+    clearScreenDown(callback?: () => void): boolean;
+    /**
+     * `writeStream.cursorTo()` moves this `WriteStream`'s cursor to the specified
+     * position.
+     * @since v0.7.7
+     * @param callback Invoked once the operation completes.
+     * @return `false` if the stream wishes for the calling code to wait for the `'drain'` event to be emitted before continuing to write additional data; otherwise `true`.
+     */
+    cursorTo(x: number, y?: number, callback?: () => void): boolean;
+    cursorTo(x: number, callback: () => void): boolean;
+    /**
+     * `writeStream.moveCursor()` moves this `WriteStream`'s cursor _relative_ to its
+     * current position.
+     * @since v0.7.7
+     * @param callback Invoked once the operation completes.
+     * @return `false` if the stream wishes for the calling code to wait for the `'drain'` event to be emitted before continuing to write additional data; otherwise `true`.
+     */
+    moveCursor(dx: number, dy: number, callback?: () => void): boolean;
+    /**
+     * Returns:
+     *
+     * * `1` for 2,
+     * * `4` for 16,
+     * * `8` for 256,
+     * * `24` for 16,777,216 colors supported.
+     *
+     * Use this to determine what colors the terminal supports. Due to the nature of
+     * colors in terminals it is possible to either have false positives or false
+     * negatives. It depends on process information and the environment variables that
+     * may lie about what terminal is used.
+     * It is possible to pass in an `env` object to simulate the usage of a specific
+     * terminal. This can be useful to check how specific environment settings behave.
+     *
+     * To enforce a specific color support, use one of the below environment settings.
+     *
+     * * 2 colors: `FORCE_COLOR = 0` (Disables colors)
+     * * 16 colors: `FORCE_COLOR = 1`
+     * * 256 colors: `FORCE_COLOR = 2`
+     * * 16,777,216 colors: `FORCE_COLOR = 3`
+     *
+     * Disabling color support is also possible by using the `NO_COLOR` and`NODE_DISABLE_COLORS` environment variables.
+     * @since v9.9.0
+     * @param [env=process.env] An object containing the environment variables to check. This enables simulating the usage of a specific terminal.
+     */
+    getColorDepth(env?: object): number;
+    /**
+     * Returns `true` if the `writeStream` supports at least as many colors as provided
+     * in `count`. Minimum support is 2 (black and white).
+     *
+     * This has the same false positives and negatives as described in `writeStream.getColorDepth()`.
+     *
+     * ```js
+     * process.stdout.hasColors();
+     * // Returns true or false depending on if `stdout` supports at least 16 colors.
+     * process.stdout.hasColors(256);
+     * // Returns true or false depending on if `stdout` supports at least 256 colors.
+     * process.stdout.hasColors({ TMUX: '1' });
+     * // Returns true.
+     * process.stdout.hasColors(2 ** 24, { TMUX: '1' });
+     * // Returns false (the environment setting pretends to support 2 ** 8 colors).
+     * ```
+     * @since v11.13.0, v10.16.0
+     * @param [count=16] The number of colors that are requested (minimum 2).
+     * @param [env=process.env] An object containing the environment variables to check. This enables simulating the usage of a specific terminal.
+     */
+    hasColors(count?: number): boolean;
+    hasColors(env?: object): boolean;
+    hasColors(count: number, env?: object): boolean;
+    /**
+     * `writeStream.getWindowSize()` returns the size of the TTY
+     * corresponding to this `WriteStream`. The array is of the type`[numColumns, numRows]` where `numColumns` and `numRows` represent the number
+     * of columns and rows in the corresponding TTY.
+     * @since v0.7.7
+     */
+    getWindowSize(): [number, number];
+    /**
+     * A `number` specifying the number of columns the TTY currently has. This property
+     * is updated whenever the `'resize'` event is emitted.
+     * @since v0.7.7
+     */
+    columns: number;
+    /**
+     * A `number` specifying the number of rows the TTY currently has. This property
+     * is updated whenever the `'resize'` event is emitted.
+     * @since v0.7.7
+     */
+    rows: number;
+    /**
+     * A `boolean` that is always `true`.
+     * @since v0.5.8
+     */
+    isTTY: boolean;
+  }
 }
 declare module "node:tty" {
   export * from "tty";