bun-types 1.3.3-canary.20251114T140703 → 1.3.3-canary.20251116T140533

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -5,14 +5,14 @@ description: "Control metadependency versions with npm overrides and Yarn resolu
5
5
 
6
6
  Bun supports npm's `"overrides"` and Yarn's `"resolutions"` in `package.json`. These are mechanisms for specifying a version range for _metadependencies_—the dependencies of your dependencies.
7
7
 
8
+ {/* prettier-ignore */}
8
9
  ```json package.json icon="file-json"
9
10
  {
10
11
  "name": "my-app",
11
12
  "dependencies": {
12
13
  "foo": "^2.0.0"
13
14
  },
14
- "overrides": {
15
- // [!code ++]
15
+ "overrides": { // [!code ++]
16
16
  "bar": "~4.4.0" // [!code ++]
17
17
  } // [!code ++]
18
18
  }
@@ -50,14 +50,14 @@ Add `bar` to the `"overrides"` field in `package.json`. Bun will defer to the sp
50
50
  overrides](https://docs.npmjs.com/cli/v9/configuring-npm/package-json#overrides) are not supported.
51
51
  </Note>
52
52
 
53
+ {/* prettier-ignore */}
53
54
  ```json package.json icon="file-json"
54
55
  {
55
56
  "name": "my-app",
56
57
  "dependencies": {
57
58
  "foo": "^2.0.0"
58
59
  },
59
- "overrides": {
60
- // [!code ++]
60
+ "overrides": { // [!code ++]
61
61
  "bar": "~4.4.0" // [!code ++]
62
62
  } // [!code ++]
63
63
  }
@@ -69,14 +69,14 @@ The syntax is similar for `"resolutions"`, which is Yarn's alternative to `"over
69
69
 
70
70
  As with `"overrides"`, _nested resolutions_ are not currently supported.
71
71
 
72
+ {/* prettier-ignore */}
72
73
  ```json package.json icon="file-json"
73
74
  {
74
75
  "name": "my-app",
75
76
  "dependencies": {
76
77
  "foo": "^2.0.0"
77
78
  },
78
- "resolutions": {
79
- // [!code ++]
79
+ "resolutions": { // [!code ++]
80
80
  "bar": "~4.4.0" // [!code ++]
81
81
  } // [!code ++]
82
82
  }
@@ -30,7 +30,7 @@ It's common for a monorepo to have the following structure:
30
30
 
31
31
  In the root `package.json`, the `"workspaces"` key is used to indicate which subdirectories should be considered packages/workspaces within the monorepo. It's conventional to place all the workspace in a directory called `packages`.
32
32
 
33
- ```json
33
+ ```json package.json icon="file-json"
34
34
  {
35
35
  "name": "my-project",
36
36
  "version": "1.0.0",
@@ -42,14 +42,22 @@ In the root `package.json`, the `"workspaces"` key is used to indicate which sub
42
42
  ```
43
43
 
44
44
  <Note>
45
- **Glob support** — Bun supports full glob syntax in `"workspaces"` (see [here](/runtime/glob#supported-glob-patterns)
46
- for a comprehensive list of supported syntax), _except_ for exclusions (e.g. `!**/excluded/**`), which are not
47
- implemented yet.
45
+ **Glob support** — Bun supports full glob syntax in `"workspaces"`, including negative patterns (e.g.
46
+ `!**/excluded/**`). See [here](https://bun.com/docs/api/glob#supported-glob-patterns) for a comprehensive list of
47
+ supported syntax.
48
48
  </Note>
49
49
 
50
+ ```json package.json icon="file-json"
51
+ {
52
+ "name": "my-project",
53
+ "version": "1.0.0",
54
+ "workspaces": ["packages/**", "!packages/**/test/**", "!packages/**/template/**"]
55
+ }
56
+ ```
57
+
50
58
  Each workspace has it's own `package.json`. When referencing other packages in the monorepo, semver or workspace protocols (e.g. `workspace:*`) can be used as the version field in your `package.json`.
51
59
 
52
- ```json
60
+ ```json packages/pkg-a/package.json icon="file-json"
53
61
  {
54
62
  "name": "pkg-a",
55
63
  "version": "1.0.0",
@@ -7,26 +7,40 @@ Configuring a development environment for Bun can take 10-30 minutes depending o
7
7
 
8
8
  If you are using Windows, please refer to [this guide](/project/building-windows)
9
9
 
10
- ## Install Dependencies
10
+ ## Using Nix (Alternative)
11
+
12
+ A Nix flake is provided as an alternative to manual dependency installation:
13
+
14
+ ```bash
15
+ nix develop
16
+ # or explicitly use the pure shell
17
+ # nix develop .#pure
18
+ export CMAKE_SYSTEM_PROCESSOR=$(uname -m)
19
+ bun bd
20
+ ```
21
+
22
+ This provides all dependencies in an isolated, reproducible environment without requiring sudo.
23
+
24
+ ## Install Dependencies (Manual)
11
25
 
12
26
  Using your system's package manager, install Bun's dependencies:
13
27
 
14
28
  <CodeGroup>
15
29
 
16
30
  ```bash macOS (Homebrew)
17
- $ brew install automake ccache cmake coreutils gnu-sed go icu4c libiconv libtool ninja pkg-config rust ruby
31
+ $ brew install automake cmake coreutils gnu-sed go icu4c libiconv libtool ninja pkg-config rust ruby sccache
18
32
  ```
19
33
 
20
34
  ```bash Ubuntu/Debian
21
- $ sudo apt install curl wget lsb-release software-properties-common cargo ccache cmake git golang libtool ninja-build pkg-config rustc ruby-full xz-utils
35
+ $ sudo apt install curl wget lsb-release software-properties-common cargo cmake git golang libtool ninja-build pkg-config rustc ruby-full xz-utils
22
36
  ```
23
37
 
24
38
  ```bash Arch
25
- $ sudo pacman -S base-devel ccache cmake git go libiconv libtool make ninja pkg-config python rust sed unzip ruby
39
+ $ sudo pacman -S base-devel cmake git go libiconv libtool make ninja pkg-config python rust sed unzip ruby
26
40
  ```
27
41
 
28
42
  ```bash Fedora
29
- $ sudo dnf install cargo ccache cmake git golang libtool ninja-build pkg-config rustc ruby libatomic-static libstdc++-static sed unzip which libicu-devel 'perl(Math::BigInt)'
43
+ $ sudo dnf install cargo clang19 llvm19 lld19 cmake git golang libtool ninja-build pkg-config rustc ruby libatomic-static libstdc++-static sed unzip which libicu-devel 'perl(Math::BigInt)'
30
44
  ```
31
45
 
32
46
  ```bash openSUSE Tumbleweed
@@ -56,6 +70,46 @@ $ brew install bun
56
70
 
57
71
  </CodeGroup>
58
72
 
73
+ ### Optional: Install `sccache`
74
+
75
+ sccache is used to cache compilation artifacts, significantly speeding up builds. It must be installed with S3 support:
76
+
77
+ ```bash
78
+ # For macOS
79
+ $ brew install sccache
80
+
81
+ # For Linux. Note that the version in your package manager may not have S3 support.
82
+ $ cargo install sccache --features=s3
83
+ ```
84
+
85
+ This will install `sccache` with S3 support. Our build scripts will automatically detect and use `sccache` with our shared S3 cache. **Note**: Not all versions of `sccache` are compiled with S3 support, hence we recommend installing it via `cargo`.
86
+
87
+ #### Registering AWS Credentials for `sccache` (Core Developers Only)
88
+
89
+ Core developers have write access to the shared S3 cache. To enable write access, you must log in with AWS credentials. The easiest way to do this is to use the [`aws` CLI](https://aws.amazon.com/cli/) and invoke [`aws configure` to provide your AWS security info](https://docs.aws.amazon.com/cli/latest/reference/configure/).
90
+
91
+ The `cmake` scripts should automatically detect your AWS credentials from the environment or the `~/.aws/credentials` file.
92
+
93
+ <details>
94
+ <summary>Logging in to the `aws` CLI</summary>
95
+
96
+ 1. Install the AWS CLI by following [the official guide](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
97
+ 2. Log in to your AWS account console. A team member should provide you with your credentials.
98
+ 3. Click your name in the top right > Security credentials.
99
+ 4. Scroll to "Access keys" and create a new access key.
100
+ 5. Run `aws configure` in your terminal and provide the access key ID and secret access key when prompted.
101
+
102
+ </details>
103
+
104
+ <details>
105
+ <summary>Common Issues You May Encounter</summary>
106
+
107
+ - To confirm that the cache is being used, you can use the `sccache --show-stats` command right after a build. This will expose very useful statistics, including cache hits/misses.
108
+ - If you have multiple AWS profiles configured, ensure that the correct profile is set in the `AWS_PROFILE` environment variable.
109
+ - `sccache` follows a server-client model. If you run into weird issues where `sccache` refuses to use S3, even though you have AWS credentials configured, try killing any running `sccache` servers with `sccache --stop-server` and then re-running the build.
110
+
111
+ </details>
112
+
59
113
  ## Install LLVM
60
114
 
61
115
  Bun requires LLVM 19 (`clang` is part of LLVM). This version requirement is to match WebKit (precompiled), as mismatching versions will cause memory allocation failures at runtime. In most cases, you can install LLVM through your system package manager:
@@ -156,7 +210,7 @@ Bun generally takes about 2.5 minutes to compile a debug build when there are Zi
156
210
  - Batch up your changes
157
211
  - Ensure zls is running with incremental watching for LSP errors (if you use VSCode and install Zig and run `bun run build` once to download Zig, this should just work)
158
212
  - Prefer using the debugger ("CodeLLDB" in VSCode) to step through the code.
159
- - Use debug logs. `BUN_DEBUG_<scope>=1` will enable debug logging for the corresponding `Output.scoped(.<scope>, false)` logs. You can also set `BUN_DEBUG_QUIET_LOGS=1` to disable all debug logging that isn't explicitly enabled. To dump debug lgos into a file, `BUN_DEBUG=<path-to-file>.log`. Debug logs are aggressively removed in release builds.
213
+ - Use debug logs. `BUN_DEBUG_<scope>=1` will enable debug logging for the corresponding `Output.scoped(.<scope>, .hidden)` logs. You can also set `BUN_DEBUG_QUIET_LOGS=1` to disable all debug logging that isn't explicitly enabled. To dump debug logs into a file, `BUN_DEBUG=<path-to-file>.log`. Debug logs are aggressively removed in release builds.
160
214
  - src/js/\*\*.ts changes are pretty much instant to rebuild. C++ changes are a bit slower, but still much faster than the Zig code (Zig is one compilation unit, C++ is many).
161
215
 
162
216
  ## Code generation scripts
@@ -327,15 +381,6 @@ bun run build -DUSE_STATIC_LIBATOMIC=OFF
327
381
 
328
382
  The built version of Bun may not work on other systems if compiled this way.
329
383
 
330
- ### ccache conflicts with building TinyCC on macOS
331
-
332
- If you run into issues with `ccache` when building TinyCC, try reinstalling ccache
333
-
334
- ```bash
335
- brew uninstall ccache
336
- brew install ccache
337
- ```
338
-
339
384
  ## Using bun-debug
340
385
 
341
386
  - Disable logging: `BUN_DEBUG_QUIET_LOGS=1 bun-debug ...` (to disable all debug logging)
@@ -219,16 +219,21 @@ Build a minimal HTTP server with `Bun.serve`, run it locally, then evolve it by
219
219
 
220
220
  Bun can also execute `"scripts"` from your `package.json`. Add the following script:
221
221
 
222
+ {/* prettier-ignore */}
222
223
  ```json package.json icon="file-code"
223
224
  {
224
225
  "name": "quickstart",
225
226
  "module": "index.ts",
226
227
  "type": "module",
227
- "scripts": {
228
- "start": "bun run index.ts"
229
- },
228
+ "private": true,
229
+ "scripts": { // [!code ++]
230
+ "start": "bun run index.ts" // [!code ++]
231
+ }, // [!code ++]
230
232
  "devDependencies": {
231
233
  "@types/bun": "latest"
234
+ },
235
+ "peerDependencies": {
236
+ "typescript": "^5"
232
237
  }
233
238
  }
234
239
  ```
@@ -276,6 +276,58 @@ This is useful for catching flaky tests or non-deterministic behavior. Each test
276
276
 
277
277
  The `--rerun-each` CLI flag will override this setting when specified.
278
278
 
279
+ ### `test.concurrentTestGlob`
280
+
281
+ Specify a glob pattern to automatically run matching test files with concurrent test execution enabled. Test files matching this pattern will behave as if the `--concurrent` flag was passed, running all tests within those files concurrently.
282
+
283
+ ```toml title="bunfig.toml" icon="settings"
284
+ [test]
285
+ concurrentTestGlob = "**/concurrent-*.test.ts"
286
+ ```
287
+
288
+ This is useful for:
289
+
290
+ - Gradually migrating test suites to concurrent execution
291
+ - Running integration tests concurrently while keeping unit tests sequential
292
+ - Separating fast concurrent tests from tests that require sequential execution
293
+
294
+ The `--concurrent` CLI flag will override this setting when specified.
295
+
296
+ ### `test.onlyFailures`
297
+
298
+ When enabled, only failed tests are displayed in the output. This helps reduce noise in large test suites by hiding passing tests. Default `false`.
299
+
300
+ ```toml title="bunfig.toml" icon="settings"
301
+ [test]
302
+ onlyFailures = true
303
+ ```
304
+
305
+ This is equivalent to using the `--only-failures` flag when running `bun test`.
306
+
307
+ ### `test.reporter`
308
+
309
+ Configure the test reporter settings.
310
+
311
+ #### `test.reporter.dots`
312
+
313
+ Enable the dots reporter, which displays a compact output showing a dot for each test. Default `false`.
314
+
315
+ ```toml title="bunfig.toml" icon="settings"
316
+ [test.reporter]
317
+ dots = true
318
+ ```
319
+
320
+ #### `test.reporter.junit`
321
+
322
+ Enable JUnit XML reporting and specify the output file path.
323
+
324
+ ```toml title="bunfig.toml" icon="settings"
325
+ [test.reporter]
326
+ junit = "test-results.xml"
327
+ ```
328
+
329
+ This generates a JUnit XML report that can be consumed by CI systems and other tools.
330
+
279
331
  ## Package manager
280
332
 
281
333
  Package management is a complex issue; to support a range of use cases, the behavior of `bun install` can be configured under the `[install]` section.
@@ -551,7 +603,7 @@ For more details see [Minimum release age](/pm/cli/install#minimum-release-age)
551
603
 
552
604
  The `bun run` command can be configured under the `[run]` section. These apply to the `bun run` command and the `bun` command when running a file or executable or script.
553
605
 
554
- Currently, `bunfig.toml` isn't always automatically loaded for `bun run` in a local project (it does check for a global `bunfig.toml`), so you might still need to pass `-c` or `-c=bunfig.toml` to use these settings.
606
+ Currently, `bunfig.toml` is only automatically loaded for `bun run` in a local project (it doesn't check for a global `.bunfig.toml`).
555
607
 
556
608
  ### `run.shell` - use the system shell or Bun's shell
557
609
 
@@ -46,29 +46,22 @@ console.log(result);
46
46
 
47
47
  This replaces all images with a thumbnail of Rick Astley and wraps each `<img>` in a link, producing a diff like this:
48
48
 
49
+ {/* prettier-ignore */}
49
50
  ```html
50
51
  <html>
51
52
  <body>
52
- <img src="/cat.jpg" /> // [!code --] <img src="dog.png" /> // [!code --]
53
- <img src="https://example.com/bird.webp" /> // [!code --]
54
- <a href="https://www.youtube.com/watch?v=dQw4w9WgXcQ" target="_blank">
55
- // [!code ++]
56
- <img src="https://img.youtube.com/vi/dQw4w9WgXcQ/maxresdefault.jpg" alt="Definitely not a rickroll" />
57
- // [!code ++]
58
- </a>
59
- // [!code ++]
60
- <a href="https://www.youtube.com/watch?v=dQw4w9WgXcQ" target="_blank">
61
- // [!code ++]
62
- <img src="https://img.youtube.com/vi/dQw4w9WgXcQ/maxresdefault.jpg" alt="Definitely not a rickroll" />
63
- // [!code ++]
64
- </a>
65
- // [!code ++]
66
- <a href="https://www.youtube.com/watch?v=dQw4w9WgXcQ" target="_blank">
67
- // [!code ++]
68
- <img src="https://img.youtube.com/vi/dQw4w9WgXcQ/maxresdefault.jpg" alt="Definitely not a rickroll" />
69
- // [!code ++]
70
- </a>
71
- // [!code ++]
53
+ <img src="/cat.jpg" /> <!-- [!code --] -->
54
+ <img src="dog.png" /> <!-- [!code --] -->
55
+ <img src="https://example.com/bird.webp" /> <!-- [!code --] -->
56
+ <a href="https://www.youtube.com/watch?v=dQw4w9WgXcQ" target="_blank"> <!-- [!code ++] -->
57
+ <img src="https://img.youtube.com/vi/dQw4w9WgXcQ/maxresdefault.jpg" alt="Definitely not a rickroll" /> <!-- [!code ++] -->
58
+ </a> <!-- [!code ++] -->
59
+ <a href="https://www.youtube.com/watch?v=dQw4w9WgXcQ" target="_blank"> <!-- [!code ++] -->
60
+ <img src="https://img.youtube.com/vi/dQw4w9WgXcQ/maxresdefault.jpg" alt="Definitely not a rickroll" /> <!-- [!code ++] -->
61
+ </a> <!-- [!code ++] -->
62
+ <a href="https://www.youtube.com/watch?v=dQw4w9WgXcQ" target="_blank"> <!-- [!code ++] -->
63
+ <img src="https://img.youtube.com/vi/dQw4w9WgXcQ/maxresdefault.jpg" alt="Definitely not a rickroll" /> <!-- [!code ++] -->
64
+ </a> <!-- [!code ++] -->
72
65
  </body>
73
66
  </html>
74
67
  ```
@@ -283,7 +283,7 @@ You can also access the `Server` object from the `fetch` handler. It's the secon
283
283
  const server = Bun.serve({
284
284
  fetch(req, server) {
285
285
  const ip = server.requestIP(req);
286
- return new Response(`Your IP is ${ip}`);
286
+ return new Response(`Your IP is ${ip.address}`);
287
287
  },
288
288
  });
289
289
  ```
@@ -107,13 +107,13 @@ Bun.serve({
107
107
 
108
108
  Once the upgrade succeeds, Bun will send a `101 Switching Protocols` response per the [spec](https://developer.mozilla.org/en-US/docs/Web/HTTP/Protocol_upgrade_mechanism). Additional `headers` can be attached to this `Response` in the call to `server.upgrade()`.
109
109
 
110
+ {/* prettier-ignore */}
110
111
  ```ts server.ts icon="/icons/typescript.svg"
111
112
  Bun.serve({
112
113
  fetch(req, server) {
113
114
  const sessionId = await generateSessionId();
114
115
  server.upgrade(req, {
115
- headers: {
116
- // [!code ++]
116
+ headers: { // [!code ++]
117
117
  "Set-Cookie": `SessionId=${sessionId}`, // [!code ++]
118
118
  }, // [!code ++]
119
119
  });
@@ -126,6 +126,8 @@ Bun.serve({
126
126
 
127
127
  Contextual `data` can be attached to a new WebSocket in the `.upgrade()` call. This data is made available on the `ws.data` property inside the WebSocket handlers.
128
128
 
129
+ To strongly type `ws.data`, add a `data` property to the `websocket` handler object. This types `ws.data` across all lifecycle hooks.
130
+
129
131
  ```ts server.ts icon="/icons/typescript.svg"
130
132
  type WebSocketData = {
131
133
  createdAt: number;
@@ -166,6 +168,10 @@ Bun.serve({
166
168
  });
167
169
  ```
168
170
 
171
+ <Info>
172
+ **Note:** Previously, you could specify the type of `ws.data` using a type parameter on `Bun.serve`, like `Bun.serve<MyData>({...})`. This pattern was removed due to [a limitation in TypeScript](https://github.com/microsoft/TypeScript/issues/26242) in favor of the `data` property shown above.
173
+ </Info>
174
+
169
175
  To connect to this server from the browser, create a new `WebSocket`.
170
176
 
171
177
  ```ts browser.js icon="file-code"
@@ -183,6 +183,29 @@ import { stuff } from "foo";
183
183
 
184
184
  The full specification of this algorithm are officially documented in the [Node.js documentation](https://nodejs.org/api/modules.html); we won't rehash it here. Briefly: if you import `from "foo"`, Bun scans up the file system for a `node_modules` directory containing the package `foo`.
185
185
 
186
+ ### NODE_PATH
187
+
188
+ Bun supports `NODE_PATH` for additional module resolution directories:
189
+
190
+ ```bash
191
+ NODE_PATH=./packages bun run src/index.js
192
+ ```
193
+
194
+ ```ts
195
+ // packages/foo/index.js
196
+ export const hello = "world";
197
+
198
+ // src/index.js
199
+ import { hello } from "foo";
200
+ ```
201
+
202
+ Multiple paths use the platform's delimiter (`:` on Unix, `;` on Windows):
203
+
204
+ ```bash
205
+ NODE_PATH=./packages:./lib bun run src/index.js # Unix/macOS
206
+ NODE_PATH=./packages;./lib bun run src/index.js # Windows
207
+ ```
208
+
186
209
  Once it finds the `foo` package, Bun reads the `package.json` to determine how the package should be imported. To determine the package's entrypoint, Bun first reads the `exports` field and checks for the following conditions.
187
210
 
188
211
  ```json package.json icon="file-json"
@@ -51,6 +51,7 @@ await client.incr("counter");
51
51
  By default, the client reads connection information from the following environment variables (in order of precedence):
52
52
 
53
53
  - `REDIS_URL`
54
+ - `VALKEY_URL`
54
55
  - If not set, defaults to `"redis://localhost:6379"`
55
56
 
56
57
  ### Connection Lifecycle
@@ -234,8 +234,8 @@ Bun.openInEditor(currentFile);
234
234
  You can override this via the `debug.editor` setting in your [`bunfig.toml`](/runtime/bunfig).
235
235
 
236
236
  ```toml bunfig.toml
237
- [debug] // [!code ++]
238
- editor = "code" // [!code ++]
237
+ [debug] # [!code ++]
238
+ editor = "code" # [!code ++]
239
239
  ```
240
240
 
241
241
  Or specify an editor with the `editor` param. You can also specify a line and column number.
@@ -184,6 +184,53 @@ This is useful for:
184
184
  - Large test suites that consume significant memory
185
185
  - Development environments with memory constraints
186
186
 
187
+ ## Test execution
188
+
189
+ ### concurrentTestGlob
190
+
191
+ Automatically run test files matching a glob pattern with concurrent test execution enabled. This is useful for gradually migrating test suites to concurrent execution or for running specific test types concurrently.
192
+
193
+ ```toml title="bunfig.toml" icon="settings"
194
+ [test]
195
+ concurrentTestGlob = "**/concurrent-*.test.ts" # Run files matching this pattern concurrently
196
+ ```
197
+
198
+ Test files matching this pattern will behave as if the `--concurrent` flag was passed, running all tests within those files concurrently. This allows you to:
199
+
200
+ - Gradually migrate your test suite to concurrent execution
201
+ - Run integration tests concurrently while keeping unit tests sequential
202
+ - Separate fast concurrent tests from tests that require sequential execution
203
+
204
+ The `--concurrent` CLI flag will override this setting when specified, forcing all tests to run concurrently regardless of the glob pattern.
205
+
206
+ #### randomize
207
+
208
+ Run tests in random order to identify tests with hidden dependencies:
209
+
210
+ ```toml title="bunfig.toml" icon="settings"
211
+ [test]
212
+ randomize = true
213
+ ```
214
+
215
+ #### seed
216
+
217
+ Specify a seed for reproducible random test order. Requires `randomize = true`:
218
+
219
+ ```toml title="bunfig.toml" icon="settings"
220
+ [test]
221
+ randomize = true
222
+ seed = 2444615283
223
+ ```
224
+
225
+ #### rerunEach
226
+
227
+ Re-run each test file multiple times to identify flaky tests:
228
+
229
+ ```toml title="bunfig.toml" icon="settings"
230
+ [test]
231
+ rerunEach = 3
232
+ ```
233
+
187
234
  ## Coverage Options
188
235
 
189
236
  ### Basic Coverage Settings
@@ -41,6 +41,15 @@ test/package-json-lint.test.ts:
41
41
  Ran 4 tests across 1 files. [0.66ms]
42
42
  ```
43
43
 
44
+ ### Dots Reporter
45
+
46
+ The dots reporter shows `.` for passing tests and `F` for failures—useful for large test suites.
47
+
48
+ ```sh terminal icon="terminal"
49
+ bun test --dots
50
+ bun test --reporter=dots
51
+ ```
52
+
44
53
  ### JUnit XML Reporter
45
54
 
46
55
  For CI/CD environments, Bun supports generating JUnit XML reports. JUnit XML is a widely-adopted format for test results that can be parsed by many CI/CD systems, including GitLab, Jenkins, and others.
package/package.json CHANGED
@@ -1,5 +1,5 @@
1
1
  {
2
- "version": "1.3.3-canary.20251114T140703",
2
+ "version": "1.3.3-canary.20251116T140533",
3
3
  "name": "bun-types",
4
4
  "license": "MIT",
5
5
  "types": "./index.d.ts",