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

package/docs/test/reporters.md

@@ -0,0 +1,108 @@
+bun test supports different output formats through reporters. This document covers both built-in reporters and how to implement your own custom reporters.
+
+## Built-in Reporters
+
+### Default Console Reporter
+
+By default, bun test outputs results to the console in a human-readable format:
+
+```sh
+test/package-json-lint.test.ts:
+✓ test/package.json [0.88ms]
+✓ test/js/third_party/grpc-js/package.json [0.18ms]
+✓ test/js/third_party/svelte/package.json [0.21ms]
+✓ test/js/third_party/express/package.json [1.05ms]
+
+ 4 pass
+ 0 fail
+ 4 expect() calls
+Ran 4 tests in 1.44ms
+```
+
+When a terminal doesn't support colors, the output avoids non-ascii characters:
+
+```sh
+test/package-json-lint.test.ts:
+(pass) test/package.json [0.48ms]
+(pass) test/js/third_party/grpc-js/package.json [0.10ms]
+(pass) test/js/third_party/svelte/package.json [0.04ms]
+(pass) test/js/third_party/express/package.json [0.04ms]
+
+ 4 pass
+ 0 fail
+ 4 expect() calls
+Ran 4 tests across 1 files. [0.66ms]
+```
+
+### JUnit XML Reporter
+
+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.
+
+#### Using the JUnit Reporter
+
+To generate a JUnit XML report, use the `--reporter=junit` flag along with `--reporter-outfile` to specify the output file:
+
+```sh
+$ bun test --reporter=junit --reporter-outfile=./junit.xml
+```
+
+This continues to output to the console as usual while also writing the JUnit XML report to the specified path at the end of the test run.
+
+#### Configuring via bunfig.toml
+
+You can also configure the JUnit reporter in your `bunfig.toml` file:
+
+```toml
+[test.reporter]
+junit = "path/to/junit.xml"  # Output path for JUnit XML report
+```
+
+#### Environment Variables in JUnit Reports
+
+The JUnit reporter automatically includes environment information as `<properties>` in the XML output. This can be helpful for tracking test runs in CI environments.
+
+Specifically, it includes the following environment variables when available:
+
+| Environment Variable                                                    | Property Name | Description            |
+| ----------------------------------------------------------------------- | ------------- | ---------------------- |
+| `GITHUB_RUN_ID`, `GITHUB_SERVER_URL`, `GITHUB_REPOSITORY`, `CI_JOB_URL` | `ci`          | CI build information   |
+| `GITHUB_SHA`, `CI_COMMIT_SHA`, `GIT_SHA`                                | `commit`      | Git commit identifiers |
+| System hostname                                                         | `hostname`    | Machine hostname       |
+
+This makes it easier to track which environment and commit a particular test run was for.
+
+#### Current Limitations
+
+The JUnit reporter currently has a few limitations that will be addressed in future updates:
+
+- `stdout` and `stderr` output from individual tests are not included in the report
+- Precise timestamp fields per test case are not included
+
+### GitHub Actions reporter
+
+Bun test automatically detects when it's running inside GitHub Actions and emits GitHub Actions annotations to the console directly. No special configuration is needed beyond installing Bun and running `bun test`.
+
+For a GitHub Actions workflow configuration example, see the [CI/CD integration](../cli/test.md#cicd-integration) section of the CLI documentation.
+
+## Custom Reporters
+
+Bun allows developers to implement custom test reporters by extending the WebKit Inspector Protocol with additional testing-specific domains.
+
+### Inspector Protocol for Testing
+
+To support test reporting, Bun extends the standard WebKit Inspector Protocol with two custom domains:
+
+1. **TestReporter**: Reports test discovery, execution start, and completion events
+2. **LifecycleReporter**: Reports errors and exceptions during test execution
+
+These extensions allow you to build custom reporting tools that can receive detailed information about test execution in real-time.
+
+### Key Events
+
+Custom reporters can listen for these key events:
+
+- `TestReporter.found`: Emitted when a test is discovered
+- `TestReporter.start`: Emitted when a test starts running
+- `TestReporter.end`: Emitted when a test completes
+- `Console.messageAdded`: Emitted when console output occurs during a test
+- `LifecycleReporter.error`: Emitted when an error or exception occurs

package/docs/test/runtime-behavior.md

@@ -0,0 +1,93 @@
+`bun test` is deeply integrated with Bun's runtime. This is part of what makes `bun test` fast and simple to use.
+
+#### `$NODE_ENV` environment variable
+
+`bun test` automatically sets `$NODE_ENV` to `"test"` unless it's already set in the environment or via .env files. This is standard behavior for most test runners and helps ensure consistent test behavior.
+
+```ts
+import { test, expect } from "bun:test";
+
+test("NODE_ENV is set to test", () => {
+  expect(process.env.NODE_ENV).toBe("test");
+});
+```
+
+#### `$TZ` environment variable
+
+By default, all `bun test` runs use UTC (`Etc/UTC`) as the time zone unless overridden by the `TZ` environment variable. This ensures consistent date and time behavior across different development environments.
+
+#### Test Timeouts
+
+Each test has a default timeout of 5000ms (5 seconds) if not explicitly overridden. Tests that exceed this timeout will fail. This can be changed globally with the `--timeout` flag or per-test as the third parameter to the test function.
+
+## Error Handling
+
+### Unhandled Errors
+
+`bun test` tracks unhandled promise rejections and errors that occur between tests. If such errors occur, the final exit code will be non-zero (specifically, the count of such errors), even if all tests pass.
+
+This helps catch errors in asynchronous code that might otherwise go unnoticed:
+
+```ts
+import { test } from "bun:test";
+
+test("test 1", () => {
+  // This test passes
+});
+
+// This error happens outside any test
+setTimeout(() => {
+  throw new Error("Unhandled error");
+}, 0);
+
+test("test 2", () => {
+  // This test also passes
+});
+
+// The test run will still fail with a non-zero exit code
+// because of the unhandled error
+```
+
+Internally, this occurs with a higher precedence than `process.on("unhandledRejection")` or `process.on("uncaughtException")`, which makes it simpler to integrate with existing code.
+
+## Using General CLI Flags with Tests
+
+Several Bun CLI flags can be used with `bun test` to modify its behavior:
+
+### Memory Usage
+
+- `--smol`: Reduces memory usage for the test runner VM
+
+### Debugging
+
+- `--inspect`, `--inspect-brk`: Attaches the debugger to the test runner process
+
+### Module Loading
+
+- `--preload`: Runs scripts before test files (useful for global setup/mocks)
+- `--define`: Sets compile-time constants
+- `--loader`: Configures custom loaders
+- `--tsconfig-override`: Uses a different tsconfig
+- `--conditions`: Sets package.json conditions for module resolution
+- `--env-file`: Loads environment variables for tests
+
+### Installation-related Flags
+
+- `--prefer-offline`, `--frozen-lockfile`, etc.: Affect any network requests or auto-installs during test execution
+
+## Watch and Hot Reloading
+
+When running `bun test` with the `--watch` flag, the test runner will watch for file changes and re-run affected tests.
+
+The `--hot` flag provides similar functionality but is more aggressive about trying to preserve state between runs. For most test scenarios, `--watch` is the recommended option.
+
+## Global Variables
+
+The following globals are automatically available in test files without importing (though they can be imported from `bun:test` if preferred):
+
+- `test`, `it`: Define tests
+- `describe`: Group tests
+- `expect`: Make assertions
+- `beforeAll`, `beforeEach`, `afterAll`, `afterEach`: Lifecycle hooks
+- `jest`: Jest global object
+- `vi`: Vitest compatibility alias for common jest methods

package/docs/test/snapshots.md

@@ -1,3 +1,7 @@
+Snapshot testing saves the output of a value and compares it against future test runs. This is particularly useful for UI components, complex objects, or any output that needs to remain consistent.
+
+## Basic snapshots
+
 Snapshot tests are written using the `.toMatchSnapshot()` matcher:
 
 ```ts
@@ -13,3 +17,52 @@ The first time this test is run, the argument to `expect` will be serialized and
 ```bash
 $ bun test --update-snapshots
 ```
+
+## Inline snapshots
+
+For smaller values, you can use inline snapshots with `.toMatchInlineSnapshot()`. These snapshots are stored directly in your test file:
+
+```ts
+import { test, expect } from "bun:test";
+
+test("inline snapshot", () => {
+  // First run: snapshot will be inserted automatically
+  expect({ hello: "world" }).toMatchInlineSnapshot();
+
+  // After first run, the test file will be updated to:
+  // expect({ hello: "world" }).toMatchInlineSnapshot(`
+  //   {
+  //     "hello": "world",
+  //   }
+  // `);
+});
+```
+
+When you run the test, Bun automatically updates the test file itself with the generated snapshot string. This makes the tests more portable and easier to understand, since the expected output is right next to the test.
+
+### Using inline snapshots
+
+1. Write your test with `.toMatchInlineSnapshot()`
+2. Run the test once
+3. Bun automatically updates your test file with the snapshot
+4. On subsequent runs, the value will be compared against the inline snapshot
+
+Inline snapshots are particularly useful for small, simple values where it's helpful to see the expected output right in the test file.
+
+## Error snapshots
+
+You can also snapshot error messages using `.toThrowErrorMatchingSnapshot()` and `.toThrowErrorMatchingInlineSnapshot()`:
+
+```ts
+import { test, expect } from "bun:test";
+
+test("error snapshot", () => {
+  expect(() => {
+    throw new Error("Something went wrong");
+  }).toThrowErrorMatchingSnapshot();
+
+  expect(() => {
+    throw new Error("Another error");
+  }).toThrowErrorMatchingInlineSnapshot();
+});
+```

package/docs/test/time.md

@@ -74,9 +74,29 @@ test("it was 2020, for a moment.", () => {
 });
 ```
 
+## Get mocked time with `jest.now()`
+
+When you're using mocked time (with `setSystemTime` or `useFakeTimers`), you can use `jest.now()` to get the current mocked timestamp:
+
+```ts
+import { test, expect, jest } from "bun:test";
+
+test("get the current mocked time", () => {
+  jest.useFakeTimers();
+  jest.setSystemTime(new Date("2020-01-01T00:00:00.000Z"));
+  
+  expect(Date.now()).toBe(1577836800000); // Jan 1, 2020 timestamp
+  expect(jest.now()).toBe(1577836800000); // Same value
+  
+  jest.useRealTimers();
+});
+```
+
+This is useful when you need to access the mocked time directly without creating a new Date object.
+
 ## Set the time zone
 
-To change the time zone, either pass the `$TZ` environment variable to `bun test`.
+By default, the time zone for all `bun test` runs is set to UTC (`Etc/UTC`) unless overridden. To change the time zone, either pass the `$TZ` environment variable to `bun test`.
 
 ```sh
 TZ=America/Los_Angeles bun test

package/docs/test/writing.md

@@ -78,9 +78,11 @@ test("wat", async () => {
 
 In `bun:test`, test timeouts throw an uncatchable exception to force the test to stop running and fail. We also kill any child processes that were spawned in the test to avoid leaving behind zombie processes lurking in the background.
 
+The default timeout for each test is 5000ms (5 seconds) if not overridden by this timeout option or `jest.setDefaultTimeout()`.
+
 ### 🧟 Zombie process killer
 
-When a test times out and processes spawned in the test via `Bun.spawn`, `Bun.spawnSync`, or `node:child_process` are not killed, they will be automatically killed and a message will be logged to the console.
+When a test times out and processes spawned in the test via `Bun.spawn`, `Bun.spawnSync`, or `node:child_process` are not killed, they will be automatically killed and a message will be logged to the console. This prevents zombie processes from lingering in the background after timed-out tests.
 
 ## `test.skip`
 
@@ -125,7 +127,7 @@ fix the test.
 
 ## `test.only`
 
-To run a particular test or suite of tests use `test.only()` or `describe.only()`. Once declared, running `bun test --only` will only execute tests/suites that have been marked with `.only()`. Running `bun test` without the `--only` option with `test.only()` declared will result in all tests in the given suite being executed _up to_ the test with `.only()`. `describe.only()` functions the same in both execution scenarios.
+To run a particular test or suite of tests use `test.only()` or `describe.only()`.
 
 ```ts
 import { test, describe } from "bun:test";
@@ -197,22 +199,121 @@ test.todoIf(macOS)("runs on posix", () => {
 });
 ```
 
-## `test.each`
+## `test.failing`
+
+Use `test.failing()` when you know a test is currently failing but you want to track it and be notified when it starts passing. This inverts the test result:
 
-To return a function for multiple cases in a table of tests, use `test.each`.
+- A failing test marked with `.failing()` will pass
+- A passing test marked with `.failing()` will fail (with a message indicating it's now passing and should be fixed)
+
+```ts
+// This will pass because the test is failing as expected
+test.failing("math is broken", () => {
+  expect(0.1 + 0.2).toBe(0.3); // fails due to floating point precision
+});
+
+// This will fail with a message that the test is now passing
+test.failing("fixed bug", () => {
+  expect(1 + 1).toBe(2); // passes, but we expected it to fail
+});
+```
+
+This is useful for tracking known bugs that you plan to fix later, or for implementing test-driven development.
+
+## Conditional Tests for Describe Blocks
+
+The conditional modifiers `.if()`, `.skipIf()`, and `.todoIf()` can also be applied to `describe` blocks, affecting all tests within the suite:
+
+```ts
+const isMacOS = process.platform === "darwin";
+
+// Only runs the entire suite on macOS
+describe.if(isMacOS)("macOS-specific features", () => {
+  test("feature A", () => {
+    // only runs on macOS
+  });
+
+  test("feature B", () => {
+    // only runs on macOS
+  });
+});
+
+// Skips the entire suite on Windows
+describe.skipIf(process.platform === "win32")("Unix features", () => {
+  test("feature C", () => {
+    // skipped on Windows
+  });
+});
+
+// Marks the entire suite as TODO on Linux
+describe.todoIf(process.platform === "linux")("Upcoming Linux support", () => {
+  test("feature D", () => {
+    // marked as TODO on Linux
+  });
+});
+```
+
+## `test.each` and `describe.each`
+
+To run the same test with multiple sets of data, use `test.each`. This creates a parametrized test that runs once for each test case provided.
 
 ```ts
 const cases = [
   [1, 2, 3],
-  [3, 4, 5],
+  [3, 4, 7],
 ];
 
 test.each(cases)("%p + %p should be %p", (a, b, expected) => {
-  // runs once for each test case provided
+  expect(a + b).toBe(expected);
+});
+```
+
+You can also use `describe.each` to create a parametrized suite that runs once for each test case:
+
+```ts
+describe.each([
+  [1, 2, 3],
+  [3, 4, 7],
+])("add(%i, %i)", (a, b, expected) => {
+  test(`returns ${expected}`, () => {
+    expect(a + b).toBe(expected);
+  });
+
+  test(`sum is greater than each value`, () => {
+    expect(a + b).toBeGreaterThan(a);
+    expect(a + b).toBeGreaterThan(b);
+  });
+});
+```
+
+### Argument Passing
+
+How arguments are passed to your test function depends on the structure of your test cases:
+
+- If a table row is an array (like `[1, 2, 3]`), each element is passed as an individual argument
+- If a row is not an array (like an object), it's passed as a single argument
+
+```ts
+// Array items passed as individual arguments
+test.each([
+  [1, 2, 3],
+  [4, 5, 9],
+])("add(%i, %i) = %i", (a, b, expected) => {
+  expect(a + b).toBe(expected);
+});
+
+// Object items passed as a single argument
+test.each([
+  { a: 1, b: 2, expected: 3 },
+  { a: 4, b: 5, expected: 9 },
+])("add($a, $b) = $expected", data => {
+  expect(data.a + data.b).toBe(data.expected);
 });
 ```
 
-There are a number of options available for formatting the case label depending on its type.
+### Format Specifiers
+
+There are a number of options available for formatting the test title:
 
 {% table %}
 
@@ -263,6 +364,68 @@ There are a number of options available for formatting the case label depending
 
 {% /table %}
 
+#### Examples
+
+```ts
+// Basic specifiers
+test.each([
+  ["hello", 123],
+  ["world", 456],
+])("string: %s, number: %i", (str, num) => {
+  // "string: hello, number: 123"
+  // "string: world, number: 456"
+});
+
+// %p for pretty-format output
+test.each([
+  [{ name: "Alice" }, { a: 1, b: 2 }],
+  [{ name: "Bob" }, { x: 5, y: 10 }],
+])("user %p with data %p", (user, data) => {
+  // "user { name: 'Alice' } with data { a: 1, b: 2 }"
+  // "user { name: 'Bob' } with data { x: 5, y: 10 }"
+});
+
+// %# for index
+test.each(["apple", "banana"])("fruit #%# is %s", fruit => {
+  // "fruit #0 is apple"
+  // "fruit #1 is banana"
+});
+```
+
+## Assertion Counting
+
+Bun supports verifying that a specific number of assertions were called during a test:
+
+### expect.hasAssertions()
+
+Use `expect.hasAssertions()` to verify that at least one assertion is called during a test:
+
+```ts
+test("async work calls assertions", async () => {
+  expect.hasAssertions(); // Will fail if no assertions are called
+
+  const data = await fetchData();
+  expect(data).toBeDefined();
+});
+```
+
+This is especially useful for async tests to ensure your assertions actually run.
+
+### expect.assertions(count)
+
+Use `expect.assertions(count)` to verify that a specific number of assertions are called during a test:
+
+```ts
+test("exactly two assertions", () => {
+  expect.assertions(2); // Will fail if not exactly 2 assertions are called
+
+  expect(1 + 1).toBe(2);
+  expect("hello").toContain("ell");
+});
+```
+
+This helps ensure all your assertions run, especially in complex async code with multiple code paths.
+
 ## Matchers
 
 Bun implements the following matchers. Full Jest compatibility is on the roadmap; track progress [here](https://github.com/oven-sh/bun/issues/1825).

package/globals.d.ts

@@ -1098,6 +1098,10 @@ interface Console {
 
 declare var console: Console;
 
+interface ImportMetaEnv {
+  [key: string]: string | undefined;
+}
+
 interface ImportMeta {
   /**
    * `file://` url string for the current module.
@@ -1130,7 +1134,7 @@ interface ImportMeta {
    * import.meta.env === process.env
    * ```
    */
-  readonly env: Bun.Env;
+  readonly env: Bun.Env & NodeJS.ProcessEnv & ImportMetaEnv;
 
   /**
    * @deprecated Use `require.resolve` or `Bun.resolveSync(moduleId, path.dirname(parent))` instead

package/overrides.d.ts

@@ -2,7 +2,7 @@ export {};
 
 declare global {
   namespace NodeJS {
-    interface ProcessEnv extends Bun.Env {}
+    interface ProcessEnv extends Bun.Env, ImportMetaEnv {}
 
     interface Process {
       readonly version: string;
@@ -57,6 +57,93 @@ declare global {
           TRACE_EVENT_PHASE_LINK_IDS: number;
         };
       };
+      binding(m: "uv"): {
+        errname(code: number): string;
+        UV_E2BIG: number;
+        UV_EACCES: number;
+        UV_EADDRINUSE: number;
+        UV_EADDRNOTAVAIL: number;
+        UV_EAFNOSUPPORT: number;
+        UV_EAGAIN: number;
+        UV_EAI_ADDRFAMILY: number;
+        UV_EAI_AGAIN: number;
+        UV_EAI_BADFLAGS: number;
+        UV_EAI_BADHINTS: number;
+        UV_EAI_CANCELED: number;
+        UV_EAI_FAIL: number;
+        UV_EAI_FAMILY: number;
+        UV_EAI_MEMORY: number;
+        UV_EAI_NODATA: number;
+        UV_EAI_NONAME: number;
+        UV_EAI_OVERFLOW: number;
+        UV_EAI_PROTOCOL: number;
+        UV_EAI_SERVICE: number;
+        UV_EAI_SOCKTYPE: number;
+        UV_EALREADY: number;
+        UV_EBADF: number;
+        UV_EBUSY: number;
+        UV_ECANCELED: number;
+        UV_ECHARSET: number;
+        UV_ECONNABORTED: number;
+        UV_ECONNREFUSED: number;
+        UV_ECONNRESET: number;
+        UV_EDESTADDRREQ: number;
+        UV_EEXIST: number;
+        UV_EFAULT: number;
+        UV_EFBIG: number;
+        UV_EHOSTUNREACH: number;
+        UV_EINTR: number;
+        UV_EINVAL: number;
+        UV_EIO: number;
+        UV_EISCONN: number;
+        UV_EISDIR: number;
+        UV_ELOOP: number;
+        UV_EMFILE: number;
+        UV_EMSGSIZE: number;
+        UV_ENAMETOOLONG: number;
+        UV_ENETDOWN: number;
+        UV_ENETUNREACH: number;
+        UV_ENFILE: number;
+        UV_ENOBUFS: number;
+        UV_ENODEV: number;
+        UV_ENOENT: number;
+        UV_ENOMEM: number;
+        UV_ENONET: number;
+        UV_ENOPROTOOPT: number;
+        UV_ENOSPC: number;
+        UV_ENOSYS: number;
+        UV_ENOTCONN: number;
+        UV_ENOTDIR: number;
+        UV_ENOTEMPTY: number;
+        UV_ENOTSOCK: number;
+        UV_ENOTSUP: number;
+        UV_EOVERFLOW: number;
+        UV_EPERM: number;
+        UV_EPIPE: number;
+        UV_EPROTO: number;
+        UV_EPROTONOSUPPORT: number;
+        UV_EPROTOTYPE: number;
+        UV_ERANGE: number;
+        UV_EROFS: number;
+        UV_ESHUTDOWN: number;
+        UV_ESPIPE: number;
+        UV_ESRCH: number;
+        UV_ETIMEDOUT: number;
+        UV_ETXTBSY: number;
+        UV_EXDEV: number;
+        UV_UNKNOWN: number;
+        UV_EOF: number;
+        UV_ENXIO: number;
+        UV_EMLINK: number;
+        UV_EHOSTDOWN: number;
+        UV_EREMOTEIO: number;
+        UV_ENOTTY: number;
+        UV_EFTYPE: number;
+        UV_EILSEQ: number;
+        UV_ESOCKTNOSUPPORT: number;
+        UV_ENODATA: number;
+        UV_EUNATCH: number;
+      };
       binding(m: string): object;
     }
 

package/package.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.2.9-canary.20250403T140620",
+  "version": "1.2.9-canary.20250405T140519",
   "name": "bun-types",
   "license": "MIT",
   "types": "./index.d.ts",