bun-types 1.2.9-canary.20250403T140620 → 1.2.9-canary.20250405T140519

package/bun.d.ts

@@ -525,7 +525,7 @@ declare module "bun" {
    *
    * Changes to `process.env` at runtime won't automatically be reflected in the default value. For that, you can pass `process.env` explicitly.
    */
-  const env: Env & NodeJS.ProcessEnv;
+  const env: Env & NodeJS.ProcessEnv & ImportMetaEnv;
 
   /**
    * The raw arguments passed to the process, including flags passed to Bun. If you want to easily read flags passed to your script, consider using `process.argv` instead.
@@ -2591,8 +2591,6 @@ declare module "bun" {
    *
    * @see [Bun.password API docs](https://bun.sh/guides/util/hash-a-password)
    *
-   * @category Security
-   *
    * The underlying implementation of these functions are provided by the Zig
    * Standard Library. Thanks to @jedisct1 and other Zig contributors for their
    * work on this.
@@ -2617,6 +2615,8 @@ declare module "bun" {
    *
    * console.log(verify); // true
    * ```
+   *
+   * @category Security
    */
   const password: {
     /**
@@ -2870,7 +2870,7 @@ declare module "bun" {
    *    outdir: './dist',
    *    env: 'inline'
    *  });
- 
+
    *  // Only include specific env vars
    *  await Bun.build({
    *    entrypoints: ['./src/index.tsx'],
@@ -2896,12 +2896,12 @@ declare module "bun" {
    *  const result = await Bun.build({
    *    entrypoints: ['./src/index.tsx']
    *  });
- 
+
    *  for (const artifact of result.outputs) {
    *    const text = await artifact.text();
    *    const buffer = await artifact.arrayBuffer();
    *    const bytes = await artifact.bytes();
- 
+
    *    new Response(artifact);
    *    await Bun.write(artifact.path, artifact);
    *  }
@@ -5889,11 +5889,19 @@ declare module "bun" {
      */
     readonly listener?: SocketListener;
 
+    readonly remoteFamily: "IPv4" | "IPv6";
+
     /**
      * Remote IP address connected to the socket
      */
     readonly remoteAddress: string;
 
+    readonly remotePort: number;
+
+    readonly localFamily: "IPv4" | "IPv6";
+
+    readonly localAddress: string;
+
     /**
      * local port connected to the socket
      */
@@ -6579,7 +6587,8 @@ declare module "bun" {
       timeout?: number;
 
       /**
-       * The signal to use when killing the process after a timeout or when the AbortSignal is aborted.
+       * The signal to use when killing the process after a timeout, when the AbortSignal is aborted,
+       * or when the process goes over the `maxBuffer` limit.
        *
        * @default "SIGTERM" (signal 15)
        *
@@ -6594,6 +6603,14 @@ declare module "bun" {
        * ```
        */
       killSignal?: string | number;
+
+      /**
+       * The maximum number of bytes the process may output. If the process goes over this limit,
+       * it is killed with signal `killSignal` (defaults to SIGTERM).
+       *
+       * @default undefined (no limit)
+       */
+      maxBuffer?: number;
     }
 
     type OptionsToSubprocess<Opts extends OptionsObject> =
@@ -6839,7 +6856,8 @@ declare module "bun" {
     resourceUsage: ResourceUsage;
 
     signalCode?: string;
-    exitedDueToTimeout?: true;
+    exitedDueToTimeout?: boolean;
+    exitedDueToMaxBuffer?: boolean;
     pid: number;
   }
 

package/docs/api/fetch.md

@@ -337,7 +337,7 @@ This will print the request and response headers to your terminal:
 ```sh
 [fetch] > HTTP/1.1 GET http://example.com/
 [fetch] > Connection: keep-alive
-[fetch] > User-Agent: Bun/1.2.9-canary.20250403T140620
+[fetch] > User-Agent: Bun/1.2.9-canary.20250405T140519
 [fetch] > Accept: */*
 [fetch] > Host: example.com
 [fetch] > Accept-Encoding: gzip, deflate, br

package/docs/api/spawn.md

@@ -120,7 +120,7 @@ You can read results from the subprocess via the `stdout` and `stderr` propertie
 ```ts
 const proc = Bun.spawn(["bun", "--version"]);
 const text = await new Response(proc.stdout).text();
-console.log(text); // => "1.2.9-canary.20250403T140620"
+console.log(text); // => "1.2.9-canary.20250405T140519"
 ```
 
 Configure the output stream by passing one of the following values to `stdout/stderr`:
@@ -253,6 +253,19 @@ const proc = Bun.spawn({
 
 The `killSignal` option also controls which signal is sent when an AbortSignal is aborted.
 
+## Using maxBuffer
+
+For spawnSync, you can limit the maximum number of bytes of output before the process is killed:
+
+```ts
+// KIll 'yes' after it emits over 100 bytes of output
+const result = Bun.spawnSync({
+  cmd: ["yes"], // or ["bun", "exec", "yes"] on windows
+  maxBuffer: 100,
+});
+// process exits
+```
+
 ## Inter-process communication (IPC)
 
 Bun supports direct inter-process communication channel between two `bun` processes. To receive messages from a spawned Bun subprocess, specify an `ipc` handler.
@@ -423,6 +436,7 @@ namespace SpawnOptions {
     signal?: AbortSignal;
     timeout?: number;
     killSignal?: string | number;
+    maxBuffer?: number;
   }
 
   type Readable =

package/docs/cli/publish.md

@@ -7,7 +7,7 @@ Use `bun publish` to publish a package to the npm registry.
 $ bun publish
 
 ## Output
-bun publish v1.2.9-canary.20250403T140620 (ca7428e9)
+bun publish v1.2.9-canary.20250405T140519 (ca7428e9)
 
 packed 203B package.json
 packed 224B README.md

package/docs/guides/ecosystem/nuxt.md

@@ -9,7 +9,7 @@ $ bunx nuxi init my-nuxt-app
 ✔ Which package manager would you like to use?
 bun
 ◐ Installing dependencies...
-bun install v1.2.9-canary.20250403T140620 (16b4bf34)
+bun install v1.2.9-canary.20250405T140519 (16b4bf34)
  + @nuxt/devtools@0.8.2
  + nuxt@3.7.0
  785 packages installed [2.67s]

package/docs/guides/install/add-peer.md

@@ -16,7 +16,7 @@ This will add the package to `peerDependencies` in `package.json`.
 ```json-diff
 {
   "peerDependencies": {
-+   "@types/bun": "^1.2.9-canary.20250403T140620"
++   "@types/bun": "^1.2.9-canary.20250405T140519"
   }
 }
 ```
@@ -28,7 +28,7 @@ Running `bun install` will install peer dependencies by default, unless marked o
 ```json-diff
 {
   "peerDependencies": {
-    "@types/bun": "^1.2.9-canary.20250403T140620"
+    "@types/bun": "^1.2.9-canary.20250405T140519"
   },
   "peerDependenciesMeta": {
 +   "@types/bun": {

package/docs/guides/install/from-npm-install-to-bun-install.md

@@ -97,7 +97,7 @@ $ bun update
 $ bun update @types/bun --latest
 
 # Update a dependency to a specific version
-$ bun update @types/bun@1.2.9-canary.20250403T140620
+$ bun update @types/bun@1.2.9-canary.20250405T140519
 
 # Update all dependencies to the latest versions
 $ bun update --latest

package/docs/guides/test/run-tests.md

@@ -21,7 +21,7 @@ Here's what the output of a typical test run looks like. In this case, there are
 
 ```sh
 $ bun test
-bun test v1.2.9-canary.20250403T140620 (9c68abdb)
+bun test v1.2.9-canary.20250405T140519 (9c68abdb)
 
 test.test.js:
 ✓ add [0.87ms]
@@ -47,7 +47,7 @@ To only run certain test files, pass a positional argument to `bun test`. The ru
 
 ```sh
 $ bun test test3
-bun test v1.2.9-canary.20250403T140620 (9c68abdb)
+bun test v1.2.9-canary.20250405T140519 (9c68abdb)
 
 test3.test.js:
 ✓ add [1.40ms]
@@ -85,7 +85,7 @@ Adding `-t add` will only run tests with "add" in the name. This works with test
 
 ```sh
 $ bun test -t add
-bun test v1.2.9-canary.20250403T140620 (9c68abdb)
+bun test v1.2.9-canary.20250405T140519 (9c68abdb)
 
 test.test.js:
 ✓ add [1.79ms]

package/docs/guides/test/snapshot.md

@@ -18,7 +18,7 @@ The first time this test is executed, Bun will evaluate the value passed into `e
 
 ```sh
 $ bun test test/snap
-bun test v1.2.9-canary.20250403T140620 (9c68abdb)
+bun test v1.2.9-canary.20250405T140519 (9c68abdb)
 
 test/snap.test.ts:
 ✓ snapshot [1.48ms]
@@ -61,7 +61,7 @@ Later, when this test file is executed again, Bun will read the snapshot file an
 
 ```sh
 $ bun test
-bun test v1.2.9-canary.20250403T140620 (9c68abdb)
+bun test v1.2.9-canary.20250405T140519 (9c68abdb)
 
 test/snap.test.ts:
 ✓ snapshot [1.05ms]
@@ -78,7 +78,7 @@ To update snapshots, use the `--update-snapshots` flag.
 
 ```sh
 $ bun test --update-snapshots
-bun test v1.2.9-canary.20250403T140620 (9c68abdb)
+bun test v1.2.9-canary.20250405T140519 (9c68abdb)
 
 test/snap.test.ts:
 ✓ snapshot [0.86ms]

package/docs/guides/test/update-snapshots.md

@@ -29,7 +29,7 @@ To regenerate snapshots, use the `--update-snapshots` flag.
 
 ```sh
 $ bun test --update-snapshots
-bun test v1.2.9-canary.20250403T140620 (9c68abdb)
+bun test v1.2.9-canary.20250405T140519 (9c68abdb)
 
 test/snap.test.ts:
 ✓ snapshot [0.86ms]

package/docs/guides/util/version.md

@@ -5,7 +5,7 @@ name: Get the current Bun version
 Get the current version of Bun in a semver format.
 
 ```ts#index.ts
-Bun.version; // => "1.2.9-canary.20250403T140620"
+Bun.version; // => "1.2.9-canary.20250405T140519"
 ```
 
 ---

package/docs/installation.md

@@ -14,7 +14,7 @@ Kernel version 5.6 or higher is strongly recommended, but the minimum is 5.1. Us
 ```bash#macOS/Linux_(curl)
 $ curl -fsSL https://bun.sh/install | bash # for macOS, Linux, and WSL
 # to install a specific version
-$ curl -fsSL https://bun.sh/install | bash -s "bun-v1.2.9-canary.20250403T140620"
+$ curl -fsSL https://bun.sh/install | bash -s "bun-v1.2.9-canary.20250405T140519"
 ```
 
 ```bash#npm
@@ -189,10 +189,10 @@ Since Bun is a single binary, you can install older versions of Bun by re-runnin
 
 ### Installing a specific version of Bun on Linux/Mac
 
-To install a specific version of Bun, you can pass the git tag of the version you want to install to the install script, such as `bun-v1.2.0` or `bun-v1.2.9-canary.20250403T140620`.
+To install a specific version of Bun, you can pass the git tag of the version you want to install to the install script, such as `bun-v1.2.0` or `bun-v1.2.9-canary.20250405T140519`.
 
 ```sh
-$ curl -fsSL https://bun.sh/install | bash -s "bun-v1.2.9-canary.20250403T140620"
+$ curl -fsSL https://bun.sh/install | bash -s "bun-v1.2.9-canary.20250405T140519"
 ```
 
 ### Installing a specific version of Bun on Windows
@@ -201,7 +201,7 @@ On Windows, you can install a specific version of Bun by passing the version num
 
 ```sh
 # PowerShell:
-$ iex "& {$(irm https://bun.sh/install.ps1)} -Version 1.2.9-canary.20250403T140620"
+$ iex "& {$(irm https://bun.sh/install.ps1)} -Version 1.2.9-canary.20250405T140519"
 ```
 
 ## Downloading Bun binaries directly

package/docs/runtime/debugger.md

@@ -124,11 +124,11 @@ await fetch("https://example.com", {
 This prints the `fetch` request as a single-line `curl` command to let you copy-paste into your terminal to replicate the request.
 
 ```sh
-[fetch] $ curl --http1.1 "https://example.com/" -X POST -H "content-type: application/json" -H "Connection: keep-alive" -H "User-Agent: Bun/1.2.9-canary.20250403T140620" -H "Accept: */*" -H "Host: example.com" -H "Accept-Encoding: gzip, deflate, br" --compressed -H "Content-Length: 13" --data-raw "{\"foo\":\"bar\"}"
+[fetch] $ curl --http1.1 "https://example.com/" -X POST -H "content-type: application/json" -H "Connection: keep-alive" -H "User-Agent: Bun/1.2.9-canary.20250405T140519" -H "Accept: */*" -H "Host: example.com" -H "Accept-Encoding: gzip, deflate, br" --compressed -H "Content-Length: 13" --data-raw "{\"foo\":\"bar\"}"
 [fetch] > HTTP/1.1 POST https://example.com/
 [fetch] > content-type: application/json
 [fetch] > Connection: keep-alive
-[fetch] > User-Agent: Bun/1.2.9-canary.20250403T140620
+[fetch] > User-Agent: Bun/1.2.9-canary.20250405T140519
 [fetch] > Accept: */*
 [fetch] > Host: example.com
 [fetch] > Accept-Encoding: gzip, deflate, br
@@ -170,7 +170,7 @@ This prints the following to the console:
 [fetch] > HTTP/1.1 POST https://example.com/
 [fetch] > content-type: application/json
 [fetch] > Connection: keep-alive
-[fetch] > User-Agent: Bun/1.2.9-canary.20250403T140620
+[fetch] > User-Agent: Bun/1.2.9-canary.20250405T140519
 [fetch] > Accept: */*
 [fetch] > Host: example.com
 [fetch] > Accept-Encoding: gzip, deflate, br

package/docs/test/configuration.md

@@ -0,0 +1,87 @@
+Configure `bun test` via `bunfig.toml` file and command-line options. This page documents the available configuration options for `bun test`.
+
+## bunfig.toml options
+
+You can configure `bun test` behavior by adding a `[test]` section to your `bunfig.toml` file:
+
+```toml
+[test]
+# Options go here
+```
+
+### Test discovery
+
+#### root
+
+The `root` option specifies a root directory for test discovery, overriding the default behavior of scanning from the project root.
+
+```toml
+[test]
+root = "src"  # Only scan for tests in the src directory
+```
+
+### Reporters
+
+#### reporter.junit
+
+Configure the JUnit reporter output file path directly in the config file:
+
+```toml
+[test.reporter]
+junit = "path/to/junit.xml"  # Output path for JUnit XML report
+```
+
+This complements the `--reporter=junit` and `--reporter-outfile` CLI flags.
+
+### Memory usage
+
+#### smol
+
+Enable the `--smol` memory-saving mode specifically for the test runner:
+
+```toml
+[test]
+smol = true  # Reduce memory usage during test runs
+```
+
+This is equivalent to using the `--smol` flag on the command line.
+
+### Coverage options
+
+In addition to the options documented in the [coverage documentation](./coverage.md), the following options are available:
+
+#### coverageSkipTestFiles
+
+Exclude files matching test patterns (e.g., \*.test.ts) from the coverage report:
+
+```toml
+[test]
+coverageSkipTestFiles = true  # Exclude test files from coverage reports
+```
+
+#### coverageThreshold (Object form)
+
+The coverage threshold can be specified either as a number (as shown in the coverage documentation) or as an object with specific thresholds:
+
+```toml
+[test]
+# Set specific thresholds for different coverage metrics
+coverageThreshold = { lines = 0.9, functions = 0.8, statements = 0.85 }
+```
+
+Setting any of these enables `fail_on_low_coverage`, causing the test run to fail if coverage is below the threshold.
+
+#### coverageIgnoreSourcemaps
+
+Internally, Bun transpiles every file. That means code coverage must also go through sourcemaps before they can be reported. We expose this as a flag to allow you to opt out of this behavior, but it will be confusing because during the transpilation process, Bun may move code around and change variable names. This option is mostly useful for debugging coverage issues.
+
+```toml
+[test]
+coverageIgnoreSourcemaps = true  # Don't use sourcemaps for coverage analysis
+```
+
+When using this option, you probably want to stick a `// @bun` comment at the top of the source file to opt out of the transpilation process.
+
+### Install settings inheritance
+
+The `bun test` command inherits relevant network and installation configuration (registry, cafile, prefer, exact, etc.) from the `[install]` section of bunfig.toml. This is important if tests need to interact with private registries or require specific install behaviors triggered during the test run.

package/docs/test/coverage.md

@@ -52,9 +52,22 @@ It is possible to specify a coverage threshold in `bunfig.toml`. If your test su
 coverageThreshold = 0.9
 
 # to set different thresholds for lines and functions
-coverageThreshold = { lines = 0.9, functions = 0.9 }
+coverageThreshold = { lines = 0.9, functions = 0.9, statements = 0.9 }
 ```
 
+Setting any of these thresholds enables `fail_on_low_coverage`, causing the test run to fail if coverage is below the threshold.
+
+### Exclude test files from coverage
+
+By default, test files themselves are included in coverage reports. You can exclude them with:
+
+```toml
+[test]
+coverageSkipTestFiles = true   # default false
+```
+
+This will exclude files matching test patterns (e.g., _.test.ts, _\_spec.js) from the coverage report.
+
 ### Sourcemaps
 
 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 `true`; this will rarely be desirable outside of advanced use cases.
@@ -64,6 +77,14 @@ Internally, Bun transpiles all files by default, so Bun automatically generates
 coverageIgnoreSourcemaps = true   # default false
 ```
 
+### Coverage defaults
+
+By default, coverage reports:
+
+1. Exclude `node_modules` directories
+2. Exclude files loaded via non-JS/TS loaders (e.g., .css, .txt) unless a custom JS loader is specified
+3. Include test files themselves (can be disabled with `coverageSkipTestFiles = true` as shown above)
+
 ### Coverage reporters
 
 By default, coverage reports will be printed to the console.

package/docs/test/discovery.md

@@ -0,0 +1,85 @@
+bun test's file discovery mechanism determines which files to run as tests. Understanding how it works helps you structure your test files effectively.
+
+## Default Discovery Logic
+
+By default, `bun test` recursively searches the project directory for files that match specific patterns:
+
+- `*.test.{js|jsx|ts|tsx}` - Files ending with `.test.js`, `.test.jsx`, `.test.ts`, or `.test.tsx`
+- `*_test.{js|jsx|ts|tsx}` - Files ending with `_test.js`, `_test.jsx`, `_test.ts`, or `_test.tsx`
+- `*.spec.{js|jsx|ts|tsx}` - Files ending with `.spec.js`, `.spec.jsx`, `.spec.ts`, or `.spec.tsx`
+- `*_spec.{js|jsx|ts|tsx}` - Files ending with `_spec.js`, `_spec.jsx`, `_spec.ts`, or `_spec.tsx`
+
+## Exclusions
+
+By default, Bun test ignores:
+
+- `node_modules` directories
+- Hidden directories (those starting with a period `.`)
+- Files that don't have JavaScript-like extensions (based on available loaders)
+
+## Customizing Test Discovery
+
+### Position Arguments as Filters
+
+You can filter which test files run by passing additional positional arguments to `bun test`:
+
+```bash
+$ bun test <filter> <filter> ...
+```
+
+Any test file with a path that contains one of the filters will run. These filters are simple substring matches, not glob patterns.
+
+For example, to run all tests in a `utils` directory:
+
+```bash
+$ bun test utils
+```
+
+This would match files like `src/utils/string.test.ts` and `lib/utils/array_test.js`.
+
+### Specifying Exact File Paths
+
+To run a specific file in the test runner, make sure the path starts with `./` or `/` to distinguish it from a filter name:
+
+```bash
+$ bun test ./test/specific-file.test.ts
+```
+
+### Filter by Test Name
+
+To filter tests by name rather than file path, use the `-t`/`--test-name-pattern` flag with a regex pattern:
+
+```sh
+# run all tests with "addition" in the name
+$ bun test --test-name-pattern addition
+```
+
+The pattern is matched against a concatenated string of the test name prepended with the labels of all its parent describe blocks, separated by spaces. For example, a test defined as:
+
+```js
+describe("Math", () => {
+  describe("operations", () => {
+    test("should add correctly", () => {
+      // ...
+    });
+  });
+});
+```
+
+Would be matched against the string "Math operations should add correctly".
+
+### Changing the Root Directory
+
+By default, Bun looks for test files starting from the current working directory. You can change this with the `root` option in your `bunfig.toml`:
+
+```toml
+[test]
+root = "src"  # Only scan for tests in the src directory
+```
+
+## Execution Order
+
+Tests are run in the following order:
+
+1. Test files are executed sequentially (not in parallel)
+2. Within each file, tests run sequentially based on their definition order

package/docs/test/dom.md

@@ -55,7 +55,7 @@ Let's run this test with `bun test`:
 
 ```bash
 $ bun test
-bun test v1.2.9-canary.20250403T140620
+bun test v1.2.9-canary.20250405T140519
 
 dom.test.ts:
 ✓ dom test [0.82ms]

package/docs/test/mocks.md

@@ -56,9 +56,9 @@ The following properties and methods are implemented on mock functions.
 - [x] [mockFn.mock.instances](https://jestjs.io/docs/mock-function-api#mockfnmockinstances)
 - [x] [mockFn.mock.contexts](https://jestjs.io/docs/mock-function-api#mockfnmockcontexts)
 - [x] [mockFn.mock.lastCall](https://jestjs.io/docs/mock-function-api#mockfnmocklastcall)
-- [x] [mockFn.mockClear()](https://jestjs.io/docs/mock-function-api#mockfnmockclear)
-- [x] [mockFn.mockReset()](https://jestjs.io/docs/mock-function-api#mockfnmockreset)
-- [x] [mockFn.mockRestore()](https://jestjs.io/docs/mock-function-api#mockfnmockrestore)
+- [x] [mockFn.mockClear()](https://jestjs.io/docs/mock-function-api#mockfnmockclear) - Clears call history
+- [x] [mockFn.mockReset()](https://jestjs.io/docs/mock-function-api#mockfnmockreset) - Clears call history and removes implementation
+- [x] [mockFn.mockRestore()](https://jestjs.io/docs/mock-function-api#mockfnmockrestore) - Restores original implementation
 - [x] [mockFn.mockImplementation(fn)](https://jestjs.io/docs/mock-function-api#mockfnmockimplementationfn)
 - [x] [mockFn.mockImplementationOnce(fn)](https://jestjs.io/docs/mock-function-api#mockfnmockimplementationoncefn)
 - [x] [mockFn.mockName(name)](https://jestjs.io/docs/mock-function-api#mockfnmocknamename)
@@ -197,7 +197,59 @@ After resolution, the mocked module is stored in the ES Module registry **and**
 
 The callback function is called lazily, only if the module is imported or required. This means that you can use `mock.module()` to mock modules that don't exist yet, and it means that you can use `mock.module()` to mock modules that are imported by other modules.
 
-## Restore all function mocks to their original values with `mock.restore()`
+### Module Mock Implementation Details
+
+Understanding how `mock.module()` works helps you use it more effectively:
+
+1. **Cache Interaction**: Module mocks interacts with both ESM and CommonJS module caches.
+
+2. **Lazy Evaluation**: The mock factory callback is only evaluated when the module is actually imported or required.
+
+3. **Path Resolution**: Bun automatically resolves the module specifier as though you were doing an import, supporting:
+   - Relative paths (`'./module'`)
+   - Absolute paths (`'/path/to/module'`)
+   - Package names (`'lodash'`)
+
+4. **Import Timing Effects**: 
+   - When mocking before first import: No side effects from the original module occur
+   - When mocking after import: The original module's side effects have already happened
+   - For this reason, using `--preload` is recommended for mocks that need to prevent side effects
+
+5. **Live Bindings**: Mocked ESM modules maintain live bindings, so changing the mock will update all existing imports
+
+## Global Mock Functions
+
+### Clear all mocks with `mock.clearAllMocks()`
+
+Reset all mock function state (calls, results, etc.) without restoring their original implementation:
+
+```ts
+import { expect, mock, test } from "bun:test";
+
+const random1 = mock(() => Math.random());
+const random2 = mock(() => Math.random());
+
+test("clearing all mocks", () => {
+  random1();
+  random2();
+  
+  expect(random1).toHaveBeenCalledTimes(1);
+  expect(random2).toHaveBeenCalledTimes(1);
+  
+  mock.clearAllMocks();
+  
+  expect(random1).toHaveBeenCalledTimes(0);
+  expect(random2).toHaveBeenCalledTimes(0);
+  
+  // Note: implementations are preserved
+  expect(typeof random1()).toBe("number");
+  expect(typeof random2()).toBe("number");
+});
+```
+
+This resets the `.mock.calls`, `.mock.instances`, `.mock.contexts`, and `.mock.results` properties of all mocks, but unlike `mock.restore()`, it does not restore the original implementation.
+
+### Restore all function mocks with `mock.restore()`
 
 Instead of manually restoring each mock individually with `mockFn.mockRestore()`, restore all mocks with one command by calling `mock.restore()`. Doing so does not reset the value of modules overridden with `mock.module()`.
 
@@ -234,3 +286,28 @@ test('foo, bar, baz', () => {
   expect(bazSpy).toBe('baz');
 });
 ```
+
+## Vitest Compatibility
+
+For added compatibility with tests written for [Vitest](https://vitest.dev/), Bun provides the `vi` global object as an alias for parts of the Jest mocking API:
+
+```ts
+import { test, expect } from "bun:test";
+
+// Using the 'vi' alias similar to Vitest
+test("vitest compatibility", () => {
+  const mockFn = vi.fn(() => 42);
+  
+  mockFn();
+  expect(mockFn).toHaveBeenCalled();
+  
+  // The following functions are available on the vi object:
+  // vi.fn
+  // vi.spyOn
+  // vi.mock
+  // vi.restoreAllMocks
+  // vi.clearAllMocks
+});
+```
+
+This makes it easier to port tests from Vitest to Bun without having to rewrite all your mocks.