--- title: Bun v1.4.3 description: "Fixes 166 issues, addressing 122 👍. bun check, a TypeScript type checker built into Bun that is 3x to 6.4x faster than tsc 7, --check for bun run, bun build and bun test, 67–89% less idle CPU, Bun.FetchSession, experimental Bun.ModuleGraph, --disallow-code-generation-from-strings, up to 2.7x faster large node:http responses, a JavaScriptCore upgrade with faster JSON.parse, faster rejected-promise handling, CompressionStream compression levels, If-Range support in Bun.serve, bun install skips tarballs it won't install, lower bun build memory with many entry points, [hashN] output names, profile-guided bytecode layout and faster startup for --compile --bytecode, and many bugfixes and Node.js compatibility improvements." date: "2026-10-10T03:18:05.517Z" author: jarred --- #### To install Bun {% codetabs %} ```sh#curl $ curl -fsSL https://bun.sh/install | bash ``` ```sh#npm $ npm install -g bun ``` ```sh#powershell $ powershell -c "irm bun.sh/install.ps1|iex" ``` ```sh#scoop $ scoop install bun ``` ```sh#brew $ brew tap oven-sh/bun $ brew install bun ``` ```sh#docker $ docker pull oven/bun $ docker run --rm --init --ulimit memlock=-1:-1 oven/bun ``` {% /codetabs %} #### To upgrade Bun ```sh $ bun upgrade ``` ## `bun check`: a TypeScript type checker built into Bun ![bun check, a TypeScript type checker built into Bun, is 3x to 7x faster than tsc 7. Type checking VS Code, 10,947 files: bun check takes 1.75 s and 2.77 GiB, tsc 7 with --checkers 16 takes 5.88 s and 9.23 GiB, and tsc 7 (typescript-go) with default settings takes 12.58 s and 7.73 GiB. That is 2.8x to 3.3x less memory. Linux x64, 64 threads, mean of 20 runs. bun check passes 100% of TypeScript's conformance tests and is a port of typescript-go.](/images/bun-check-1.4.3.webp) `bun check` is an incredibly fast TypeScript type checker that passes 100% of TypeScript 7.0.2's conformance test suite. ```sh $ bun check 1 | import { greet } from "./user"; 2 | 3 | const message = greet({ id: "1", name: "Ada" }); ^ error: TS2322: Type 'string' is not assignable to type 'number'. at src/index.ts:3:25 Found 1 error in 1 file, checked 2 files [14.00ms] ``` It's 3x to 6.4x faster than `tsc` 7.0.2, on a 16-core Apple silicon Mac: | Project | Files | `bun check` | `tsc` 7.0.2 | Faster | | ----------------------- | ----: | ----------: | ----------: | -----: | | VS Code `src` | 9,795 | 1.24 s | 5.98 s | 4.8x | | mikro-orm | 2,883 | 1.20 s | 5.97 s | 5.0x | | Next.js `packages/next` | 2,881 | 0.28 s | 1.82 s | 6.4x | | Next.js, root | 3,547 | 0.42 s | 1.28 s | 3.1x | | Storybook `scripts` | 1,039 | 0.27 s | 0.96 s | 3.5x | | Nuxt | 839 | 0.27 s | 0.80 s | 3.0x | | Playwright | 706 | 0.15 s | 0.64 s | 4.2x | | lit `packages/react` | 6 | 0.46 s | 2.12 s | 4.6x | And it uses 2.2x to 4.9x less memory: | Project | Files | `bun check` | `tsc` 7.0.2 | Less | | ----------------------- | ----: | ----------: | ----------: | ---: | | VS Code `src` | 9,795 | 2.14 GB | 7.97 GB | 3.7x | | mikro-orm | 2,883 | 1.35 GB | 6.67 GB | 4.9x | | Next.js `packages/next` | 2,881 | 0.71 GB | 1.81 GB | 2.5x | | Next.js, root | 3,547 | 0.55 GB | 1.33 GB | 2.4x | | Storybook `scripts` | 1,039 | 0.56 GB | 1.39 GB | 2.5x | | Nuxt | 839 | 0.51 GB | 1.14 GB | 2.2x | | Playwright | 706 | 0.46 GB | 1.06 GB | 2.3x | | lit `packages/react` | 6 | 0.24 GB | 0.63 GB | 2.6x | It's a port of [typescript-go](https://github.com/microsoft/typescript-go). It reads your `tsconfig.json`, reports the same errors as `tsc`, and uses every CPU core. You don't need the `typescript` package installed. It only type checks. It doesn't emit JavaScript or `.d.ts` files, and there's no language server, so your editor keeps using TypeScript. ### `bun run --check` Type check, then run. If there's a type error, your code doesn't run. ```sh $ bun run --check src/index.ts 1 | import { greet } from "./user"; 2 | 3 | console.log(greet({ id: "1", name: "Ada" })); ^ error: TS2322: Type 'string' is not assignable to type 'number'. at src/index.ts:3:21 2 | id: number; ^ note: The expected type comes from property 'id' which is declared here on type 'User' at src/user.ts:2:3 Found 1 error in 1 file, checked 2 files [24.00ms] ``` It also works with `package.json` scripts (`bun run --check dev`) and with `--watch`, which checks again before every restart. ### `bun test --check` Type check the test files and everything they import, then run the tests. If there's a type error, no tests run. ```sh $ bun test --check bun test v1.4.3 4 | test("greet", () => { 5 | expect(greet({ id: "1", name: "Ada" })).toBe("hello Ada"); ^ error: TS2322: Type 'string' is not assignable to type 'number'. at src/user.test.ts:5:18 2 | id: number; ^ note: The expected type comes from property 'id' which is declared here on type 'User' at src/user.ts:2:3 Found 1 error in 1 file, checked 2 files [23.94ms] ``` ### `bun build --check` Type check, then bundle. A type error fails the build like any other build error, and nothing is written. ```sh $ bun build --check ./src/index.ts --outdir out 3 | console.log(greet({ id: "1", name: "Ada" })); ^ error: TS2322: Type 'string' is not assignable to type 'number'. at /app/src/index.ts:3:21 2 | id: number; ^ note: TS6500: The expected type comes from property 'id' which is declared here on type 'User' at /app/src/user.ts:2:3 ``` `Bun.build` takes `check: true`. ### Testing `bun check` Every commit of Bun runs TypeScript 7.0.2's complete conformance test suite (and we will continue to keep it up-to-date as TypeScript itself updates). | Baseline | What it checks | Tests | Passing | | ----------------- | ---------------------------- | ---------: | ---------: | | Errors | Every error | 13,101 | 13,101 | | Types | The type of every expression | 12,463 | 12,463 | | Symbols | The symbol behind every name | 12,463 | 12,463 | | Declarations | Emitted `.d.ts` files | 13,032 | 13,032 | | Module resolution | How every import resolves | 151 | 151 | | **Total** | | **51,210** | **51,210** | #### 72 misconfigured open-source projects For a project as complex as a TypeScript type checker, conformance tests aren't enough, so we deliberately misconfigured 72 popular open-source repositories and compared `bun check`'s output with `tsc`'s output. Missing `node_modules`, mismatched TypeScript versions, no build step. Every error has to match: same file, line, column and error code. | Project | Configs | Identical | Errors | Mismatches | | --------------------------------------------------------------------------------------------- | --------: | --------: | ----------: | ---------: | | [anthropics/anthropic-sdk-typescript](https://github.com/anthropics/anthropic-sdk-typescript) | 16 | 16 | 596 | 0 | | [apollographql/apollo-client](https://github.com/apollographql/apollo-client) | 7 | 7 | 559 | 0 | | [arktypeio/arktype](https://github.com/arktypeio/arktype) | 5 | 5 | 389 | 0 | | [axios/axios](https://github.com/axios/axios) | 1 | 1 | 105 | 0 | | [colinhacks/zod](https://github.com/colinhacks/zod) | 10 | 10 | 191 | 0 | | [date-fns/date-fns](https://github.com/date-fns/date-fns) | 3 | 3 | 1 | 0 | | [discordjs/discord.js](https://github.com/discordjs/discord.js) | 2 | 2 | 3 | 0 | | [drizzle-team/drizzle-orm](https://github.com/drizzle-team/drizzle-orm) | 3 | 3 | 10,786 | 0 | | [Effect-TS/effect](https://github.com/Effect-TS/effect) | 10 | 10 | 2 | 0 | | [elysiajs/elysia](https://github.com/elysiajs/elysia) | 4 | 4 | 53 | 0 | | [excalidraw/excalidraw](https://github.com/excalidraw/excalidraw) | 7 | 7 | 11,048 | 0 | | [fabian-hiller/valibot](https://github.com/fabian-hiller/valibot) | 2 | 2 | 1 | 0 | | [fastify/fastify](https://github.com/fastify/fastify) | 1 | 1 | 0 | 0 | | [gcanti/fp-ts](https://github.com/gcanti/fp-ts) | 2 | 2 | 3 | 0 | | [gcanti/io-ts](https://github.com/gcanti/io-ts) | 2 | 2 | 3 | 0 | | [graphql/graphql-js](https://github.com/graphql/graphql-js) | 3 | 3 | 24 | 0 | | [gvergnaud/ts-pattern](https://github.com/gvergnaud/ts-pattern) | 2 | 2 | 2 | 0 | | [honojs/hono](https://github.com/honojs/hono) | 6 | 6 | 14,239 | 0 | | [immerjs/immer](https://github.com/immerjs/immer) | 1 | 1 | 5 | 0 | | [jquense/yup](https://github.com/jquense/yup) | 1 | 1 | 1 | 0 | | [kysely-org/kysely](https://github.com/kysely-org/kysely) | 6 | 6 | 1,185 | 0 | | [langchain-ai/langchainjs](https://github.com/langchain-ai/langchainjs) | 41 | 41 | 5,273 | 0 | | [lit/lit](https://github.com/lit/lit) | 34 | 34 | 2,588 | 0 | | [microsoft/playwright](https://github.com/microsoft/playwright) | 4 | 4 | 22 | 0 | | [microsoft/TypeScript](https://github.com/microsoft/TypeScript) | 4 | 4 | 613 | 0 | | [microsoft/vscode](https://github.com/microsoft/vscode), its own build | 1 | 1 | 0 | 0 | | microsoft/vscode, extensions and tests | 105 | 105 | 5,685 | 0 | | [mikro-orm/mikro-orm](https://github.com/mikro-orm/mikro-orm) | 17 | 17 | 87,981 | 0 | | [millsp/ts-toolbelt](https://github.com/millsp/ts-toolbelt) | 1 | 1 | 3 | 0 | | [mobxjs/mobx](https://github.com/mobxjs/mobx) | 3 | 3 | 186 | 0 | | [mswjs/msw](https://github.com/mswjs/msw) | 10 | 10 | 5,878 | 0 | | [nestjs/nest](https://github.com/nestjs/nest) | 30 | 30 | 27,345 | 0 | | [nuxt/nuxt](https://github.com/nuxt/nuxt) | 3 | 3 | 11 | 0 | | [openai/openai-node](https://github.com/openai/openai-node) | 4 | 4 | 6 | 0 | | [pmndrs/jotai](https://github.com/pmndrs/jotai) | 2 | 2 | 7 | 0 | | [pmndrs/valtio](https://github.com/pmndrs/valtio) | 1 | 1 | 0 | 0 | | [pmndrs/zustand](https://github.com/pmndrs/zustand) | 1 | 1 | 0 | 0 | | [preactjs/preact](https://github.com/preactjs/preact) | 1 | 1 | 1 | 0 | | [prisma/prisma](https://github.com/prisma/prisma) | 44 | 44 | 24,201 | 0 | | [puppeteer/puppeteer](https://github.com/puppeteer/puppeteer) | 10 | 10 | 2,701 | 0 | | [react-hook-form/react-hook-form](https://github.com/react-hook-form/react-hook-form) | 2 | 2 | 3 | 0 | | [ReactiveX/rxjs](https://github.com/ReactiveX/rxjs) | 10 | 10 | 22,271 | 0 | | [reduxjs/redux](https://github.com/reduxjs/redux) | 1 | 1 | 0 | 0 | | [reduxjs/redux-toolkit](https://github.com/reduxjs/redux-toolkit) | 8 | 8 | 142 | 0 | | [remeda/remeda](https://github.com/remeda/remeda) | 7 | 7 | 13 | 0 | | [remix-run/react-router](https://github.com/remix-run/react-router) | 14 | 14 | 6,735 | 0 | | [rollup/rollup](https://github.com/rollup/rollup) | 9 | 9 | 107 | 0 | | [sequelize/sequelize](https://github.com/sequelize/sequelize) | 16 | 16 | 6,768 | 0 | | [sindresorhus/got](https://github.com/sindresorhus/got) | 1 | 1 | 2 | 0 | | [sindresorhus/ky](https://github.com/sindresorhus/ky) | 2 | 2 | 52 | 0 | | [sindresorhus/type-fest](https://github.com/sindresorhus/type-fest) | 2 | 2 | 0 | 0 | | [solidjs/solid](https://github.com/solidjs/solid) | 7 | 7 | 740 | 0 | | [statelyai/xstate](https://github.com/statelyai/xstate) | 8 | 8 | 545 | 0 | | [storybookjs/storybook](https://github.com/storybookjs/storybook) | 19 | 19 | 1,401 | 0 | | [stripe/stripe-node](https://github.com/stripe/stripe-node) | 4 | 4 | 42 | 0 | | [sveltejs/svelte](https://github.com/sveltejs/svelte) | 5 | 5 | 186 | 0 | | [TanStack/form](https://github.com/TanStack/form) | 13 | 13 | 124 | 0 | | [TanStack/query](https://github.com/TanStack/query) | 15 | 15 | 686 | 0 | | [TanStack/router](https://github.com/TanStack/router) | 29 | 29 | 4,853 | 0 | | [TanStack/table](https://github.com/TanStack/table) | 20 | 20 | 574 | 0 | | [tldraw/tldraw](https://github.com/tldraw/tldraw) | 4 | 4 | 0 | 0 | | [total-typescript/ts-reset](https://github.com/total-typescript/ts-reset) | 2 | 2 | 4 | 0 | | [typeorm/typeorm](https://github.com/typeorm/typeorm) | 4 | 4 | 959 | 0 | | [typescript-eslint/typescript-eslint](https://github.com/typescript-eslint/typescript-eslint) | 35 | 35 | 18,392 | 0 | | [unjs/h3](https://github.com/unjs/h3) | 1 | 1 | 0 | 0 | | [unjs/nitro](https://github.com/unjs/nitro) | 5 | 5 | 742 | 0 | | [urql-graphql/urql](https://github.com/urql-graphql/urql) | 2 | 2 | 17 | 0 | | [vercel/ai](https://github.com/vercel/ai) | 52 | 52 | 9,742 | 0 | | [vercel/next.js](https://github.com/vercel/next.js) | 356 | 356 | 3,690 | 0 | | [vercel/swr](https://github.com/vercel/swr) | 4 | 4 | 314 | 0 | | [vitest-dev/vitest](https://github.com/vitest-dev/vitest) | 18 | 18 | 2,111 | 0 | | [vuejs/core](https://github.com/vuejs/core) | 6 | 5 | 1,359 | 1 | | [withastro/astro](https://github.com/withastro/astro) | 12 | 12 | 1,996 | 0 | | **All 72** | **1,103** | **1,102** | **286,267** | **1** | The one mismatch is in vuejs/core. `tsc` only reports that error when `global.ts` comes before `model.ts` in `files`. We ran 69 of them again under 11 other sets of compiler options: | Compiler options | Projects | Identical | Errors | Mismatches | | ------------------------------------------ | -------: | --------: | ----------: | ---------: | | Every strictness flag on | 69 | 69 | 100,756 | 0 | | `strict` off | 69 | 68 | 76,960 | 12 | | `skipLibCheck` off | 69 | 69 | 90,609 | 0 | | `checkJs` | 69 | 69 | 84,122 | 0 | | `declaration` | 69 | 69 | 80,495 | 0 | | `isolatedModules` + `verbatimModuleSyntax` | 69 | 69 | 80,622 | 0 | | `isolatedDeclarations` | 62 | 62 | 34,982 | 0 | | `erasableSyntaxOnly` + legacy decorators | 69 | 69 | 71,577 | 0 | | `nodenext` | 69 | 69 | 85,238 | 0 | | `"types": []` | 69 | 69 | 105,818 | 0 | | `"lib": ["es5"]` | 69 | 69 | 83,872 | 0 | | **All 11** | **752** | **751** | **895,051** | **12** | #### Fuzzing & mutation testing Each fuzzer generates every combination of a set of language features, runs `tsc` and `bun check` on the result, and diffs the output. | Fuzzer | Functions | Mismatches | | -------------------------------------------------- | ----------: | ---------: | | Control flow narrowing | 46,080 | 0 | | Variables with no type annotation | 29,484 | 0 | | Variables reassigned inside 12 kinds of loop | 20,304 | 0 | | Callbacks and contextual typing | 9,984 | 0 | | Circular references | 9,196 | 0 | | Interfaces that extend a mapped type of themselves | 8,424 | 0 | | Index signatures | 5,770 | 0 | | Circular references next to overloaded calls | 3,888 | 0 | | Boolean assignability | 1,664 | 0 | | 8 smaller fuzzers | 1,441 | 0 | | **Total** | **136,235** | **0** | Those run on every commit. These are larger runs we did offline: | Fuzzer | Programs | Mismatches | | --------------------------------------------------- | ------------: | ---------: | | Overloads, inference and variance | 1,300,000 | 0 | | Where long types get cut off in error messages | 1,060,000 | 0 | | Classes: access, overrides, initialization, `super` | 290,000 | 0 | | Duplicate declarations of a variable or property | 123,891 | 0 | | JSDoc in type-checked JavaScript | 68,334 | 0 | | JSX: tags, attributes and children | 63,770 | 0 | | Annotations that refer to what's being declared | 50,688 | 95 | | Class expressions that refer to what holds them | 40,128 | 21 | | Immediately invoked functions | 19,200 | 21 | | Symbols that `tsc` creates lazily | 15,444 | 25 | | Infinitely recursive type aliases | 517 | 28 | | Module augmentation through re-exports | 210 | 1 | | **Total** | **3,032,182** | **191** | 162 of the 191 mismatches are in code that refers to itself while it's being declared, like `class A { x = { a: null! as { p: A["x"] } } }`. For mutation testing, we broke [Effect](https://github.com/Effect-TS/effect)'s source 913 times (swapped arguments, dropped type arguments, deleted overloads) and compared every error. | Mutations | Errors in `tsc` | Missing in `bun check` | Only in `bun check` | | --------: | --------------: | ---------------------: | ------------------: | | 913 | 2,925 | 0 | 0 | | Also on every commit | Count | | -------------------------------------------------------------------------------- | ------: | | Fuzzer-generated functions, diffed against `tsc` | 136,235 | | Edge cases found by reading typescript-go next to the port, diffed against `tsc` | 2,362 | | Corrupted source files that still have to report an error | 1,893 | | Generated projects: file name casing, malformed `tsconfig.json`, `references` | 656 | | Regression tests | 576 | #### Try it on your project ```sh bunx -p typescript@7.0.2 tsc --noEmit --pretty false > tsc.txt bun check --no-pretty > bun.txt diff tsc.txt bun.txt ``` If there's a difference, that's a bug in Bun. Please [open an issue](https://github.com/oven-sh/bun/issues). [Read the `bun check` docs](/docs/runtime/check). ## New in the runtime ### 67–89% less CPU while your server sleeps ![Bun v1.4.3 uses 67–89% less CPU than v1.4.2 while your server sleeps. In one idle minute, v1.4.2 woke up every second, because any occasional request kept the 1-second GC timer running. v1.4.3 wakes only for the health check, every 10 seconds. CPU ms in 2 idle minutes on v1.3.14, v1.4.0, v1.4.2 and v1.4.3: Express 430, 308, 282, 57. Fastify 450, 284, 267, 57. Elysia 473, 280, 197, 21. Hono 417, 263, 195, 21. Next.js SSR 7,029, 628, 815, 268. 6–11% less idle memory than v1.4.2. Measured after a 30 s load test with one health check every 10 s, on Linux x64.](/images/idle-cpu-1.4.3.webp) ### `Bun.FetchSession` `Bun.FetchSession` gives a group of requests their own TLS, proxy, and keep-alive settings and their own connection pool. Sessions never share connections with each other or with plain `fetch()`. ```ts const session = new Bun.FetchSession({ tls: { ca: await Bun.file("corp-ca.pem").text() }, proxy: { url: "http://proxy.internal:8080" }, keepAlive: { idleTimeout: 30, maxIdleSockets: 8 }, }); const client = new SomeClient({ fetch: session.fetch }); await fetch("https://example.com", { session }); // same thing ``` - `session.fetch` is bound, so any client that accepts a `fetch` function can use it. - Options on the request override the session's. - `session.close()` (or `using`) closes idle connections. - A session's `tls.checkServerIdentity` runs once per connection. Requests that reuse the connection skip it. ### Better proxy environment support in `fetch()` `NO_PROXY` accepts wildcards, CIDR blocks, bare IPv6 addresses, and `host:port`. ```sh NO_PROXY="*.internal.example.com, 10.0.0.0/8, fd00::/8, localhost:3000" ``` `ALL_PROXY` is used when `HTTP_PROXY` / `HTTPS_PROXY` is unset. `proxy: false` ignores the proxy environment for one request. ```ts await fetch("https://example.com", { proxy: false }); ``` When a proxy refuses `CONNECT` with a non-2xx status, `fetch()` rejects with `ERR_PROXY_TUNNEL`. The error carries the proxy's `status` and `headers`. Before, `fetch()` resolved with the proxy's reply as if it came from the origin. ### Experimental: `Bun.ModuleGraph` Run many instances of one app in a single process. Each graph gets fresh module state, its own `require.cache`, and its own timers and I/O. Parsed code and bytecode are shared between graphs. ```ts const graph = new Bun.ModuleGraph({ globals: { process: tenantProcess }, onError: (error, kind) => console.error(kind, error), }); const app = await graph.import("./app.ts"); await graph.run(() => app.handle(request)); graph.dispose(); // closes the graph's servers, sockets, timers, child processes ``` - `graph.run(fn, ...args)` calls `fn` in the graph's context, so what it opens belongs to the graph. - `graph.dispose()` (or `using`) behaves like `worker.terminate()`. It is not a security sandbox. - `Bun.ModuleGraph.current` is the graph whose context the caller is in. ### `--disallow-code-generation-from-strings` blocks `eval()` and `new Function()` With Node's `--disallow-code-generation-from-strings` flag, `eval()` and `new Function()` throw. It covers the whole process, including every `Worker`. Bun used to accept the flag and ignore it. ```ts new Function("return 1 + 1"); // EvalError: Code generation from strings disallowed for this context ``` `=strict` is Bun-only. It also blocks every other way a string becomes code: `node:vm`, `import()` of a `data:` URL, `new Worker(code, { eval: true })`, `module._compile()`, plugins that return source text, `napi_run_script()` and the inspector. A flag embedded in a compiled executable always applies. `BUN_OPTIONS` can raise the level but not lower it. ```sh $ bun build --compile ./server.ts --outfile server \ --compile-exec-argv="--disallow-code-generation-from-strings=strict" ``` ### Up to 2.7x faster large responses in `node:http` A response over 16 KB now goes out in one write per tick instead of up to 16. It applies to `node:http` and `Bun.serve`, over HTTP and HTTPS. Requests per second from a `node:http` server: | Response | After | Before | Node.js 26.3 | | ----------------------------- | -----: | -----: | -----------: | | 4 × `res.write(16 KB)` | 19,160 | 6,983 | 17,735 | | 4 × `res.write(16 KB)`, HTTPS | 15,510 | 6,110 | 11,720 | | 40 × `res.write(2 KB)` | 14,980 | 6,140 | 9,879 | | `res.end(64 KB)` | 19,889 | 16,528 | 18,535 | `node:http` was slower than Node in six of eight large-response benchmarks. Now it's faster in all eight. A `Bun.serve` direct stream writing 4 × 16 KB is 83% faster. Small responses are unchanged. ### JavaScriptCore upgrade Bun's JavaScriptCore engine picks up upstream WebKit performance work and spec fixes. | Operation | Change | | ------------------------------------------------------ | ---------------------------- | | `JSON.parse()` on npm registry manifests | 1.2x–1.5x faster | | `JSON.parse()` on 1,000 objects with the same keys | 1.5x faster | | `/^\/users\/(\d+)$/.test(path)` in a router benchmark | ~5x faster | | `Object.values(obj)` with 9+ properties | 2.3x–3.2x faster | | `arr.copyWithin(0, 1)` | ~2x faster, ~45x with holes | | `arr.includes(x)` on long number arrays | 2.4x–3.3x faster | | `arr.splice(2, 1, x)` | new fast path | | `for (const x of arr)`, and the same for strings | no iterator object allocated | | `const [a, b] = arr` | no iterator object allocated | The `JSON.parse` numbers are against Bun v1.4.2 on an Apple silicon Mac, with manifests from 331 KB to 8 MB. The `for...of` and destructuring change helps code that hasn't reached the top JIT tier yet. - WebAssembly wide arithmetic (`i64.add128`, `i64.mul_wide_u` and friends) is on by default. - `RegExp.escape()` no longer escapes supplementary code points like U+2002A. - `Atomics.isLockFree(4294967297)` returns `false` instead of wrapping to `1`. - A strict-mode async generator that does `return someCall()` awaits the returned promise. - `++arr.length` in a loop no longer slows down quadratically past 100,000 elements. - `BigInt("-")`, `BigInt("+")` and `BigInt("0x")` throw `SyntaxError` instead of returning `0n`. - `(a?.b)(x)` throws a `TypeError` when `a` is `null` or `undefined`. Before, it returned `undefined`, as if the parentheses weren't there. - `` super.tag`x` `` calls `tag` with the current `this`. - `Error.stackTraceLimit` is read from the `Error` constructor when a stack is captured, like V8. `node:vm` contexts start at 10, matching Node. - JIT-optimized code with many live floating-point values no longer turns one into `NaN` after reading `arr[i]`. This could happen if `arr` was sometimes a `Float32Array` or `Float64Array` and sometimes another kind of object. - `Intl.DurationFormat` keeps the minus sign of a duration between -1 and 0. With `seconds: "numeric"`, `{ milliseconds: -500 }` formats as `-0.5` instead of `0.5`. - `Intl.Segmenter`'s `containing(index)` returns the right segment when `index` is the first half of a surrogate pair, like the start of an emoji. - On Windows, WebAssembly fast memory is enabled again. Growing a WebAssembly memory or a resizable `ArrayBuffer` at the system commit limit throws instead of crashing. - `--bytecode` output is 3–6% smaller. ### Faster handling of many rejected promises `Promise.allSettled` over thousands of throwing async calls no longer stalls. Attaching handlers to many promises that reject in the same turn took quadratic time. It is linear now. ```ts await Promise.allSettled( Array.from({ length: 100_000 }, async () => { throw new Error("nope"); }), ); ``` | | Time | | ------- | -----: | | After | 148 ms | | Before | 24 s | | Node.js | 475 ms | Attaching `.catch()` to 160,000 already-rejected promises went from 83 s to 24 ms. ### `CompressionStream` accepts a compression level Pass a `level` option to `CompressionStream` to trade ratio for speed. Brotli previously always ran at quality 11, which is very slow for large, dynamic responses. ```ts const stream = new CompressionStream("brotli", { level: 4 }); ``` - `gzip`, `deflate`, `deflate-raw`: 0-9 - `brotli`: 0-11 - `zstd`: 1-22 Out-of-range values throw a `RangeError`. Omitting `level` keeps each format's current default. ### `Bun.serve` supports `If-Range` Clients can safely resume a download from `Bun.serve`. A `Range` request with `If-Range` gets the range only if the file hasn't changed. Otherwise it gets the full body. ```ts await fetch("http://localhost:3000/big.bin", { headers: { Range: "bytes=1000-", "If-Range": lastModified, // from the first response }, }); // 206 if the file is unchanged, 200 with the full body if it changed ``` It works for `Bun.file` responses and `{ dir }` routes. ## New in `bun install` ### `bun install` skips tarballs it won't install Without a lockfile, `bun install` and `bun add` no longer download tarballs for packages that never land in `node_modules`: bundled dependencies, packages for other platforms, and groups turned off by `--production` or `--omit`. Tarballs downloaded with a cold cache and no lockfile: | Install | After | Before | | ------------------------------------ | ----: | -----: | | `npm@10.9.2` | 1 | 196 | | `express` + dev deps, `--production` | 69 | 403 | ## New in `bun build` ### Lower memory usage in `bun build` with many entry points Builds with many entry points or chunks use much less memory. | Peak RSS, 800 entry points | After | Before | | ---------------------------------------------------------------------- | -----: | -------: | | Each imports one export from a file with 200,000 exports, `--splitting` | 276 MB | 2,121 MB | | 13 modules each, with or without `--splitting` | 200 MB | 405 MB | This fixes a regression from Bun v1.4.1 where `bun build --splitting` with ~800 chunks peaked at 7.7 GB instead of 6.2 GB. On Windows, it could abort with `memory allocation of N bytes failed`. ### `Bun.build` supports `[hashN]` in output names Large `--splitting` builds no longer fail with "Multiple files share the same output path". Before, two chunks with different contents could get the same 8-character `[hash]` name. Now both names get extra hash characters until they differ. Use `[hash9]` through `[hash13]` to set a wider minimum hash. `[hash13]` is the full 64-bit hash. ```ts await Bun.build({ entrypoints: ["./src/index.ts"], outdir: "./dist", splitting: true, naming: { chunk: "chunk-[hash13].[ext]" }, }); ``` ### Metafile names the input file behind a split `import()` With `--splitting`, each dynamic `import()` in `metafile.inputs` has an `entryPoint` field naming the input file it loads, so tools that build a module graph no longer have to join through `outputs`. Metafile byte counts and `--metafile-md` output are now accurate too. ```json#meta.json { "path": "./chunk-abc123.js", "kind": "dynamic-import", "original": "./lazy.js", "entryPoint": "lazy.js", "external": true } ``` - `entryPoint` is a key of `inputs`. A `require()` of an ES module with `--target=bun` gets one too. True externals like `import("node:fs")` don't. ## New in `bun build --compile` ### `bun build --compile` supports profile-guided bytecode layout `--bytecode-order` lays out a `--compile --bytecode` executable from a profile of a real run. The bytecode that run used goes together at the front of the file. In one large CLI app, cold start went from 1.01s to 0.53s. Resident bytecode memory at its prompt went from 59.5 MB to 20.5 MB. ```sh bun build --compile --bytecode ./cli.ts --outfile myapp # Run it the way your users do. The profile is written on exit. BUN_BYTECODE_ORDER_OUT=myapp.order ./myapp --help bun build --compile --bytecode --bytecode-order=myapp.order ./cli.ts --outfile myapp ``` - Functions are matched by a hash of their syntax, so a profile from an older build still applies. - `--bytecode-order=a.order,b.order` takes several profiles, most common first. - `Bun.build` uses `compile: { bytecodeOrder: "./myapp.order" }`. - `bytecodeOrderStats()` from `bun:jsc` reports how many loaded functions the profile covered. ### Faster startup for `--compile --bytecode` executables Executables built with `bun build --compile --bytecode` start faster. ESM executables embed a pre-resolved module graph and optimized bytecode and load every bundled module in one pass, and JavaScriptCore does less work to decode embedded bytecode and link compiled functions. On a ~2,300-module CLI app, time to the first interactive prompt went from 698 ms to 579 ms (−17%). On a ~2,000-module CLI, the bytecode decode changes alone cut 6.3% of instructions to its first prompt. ```sh $ bun build ./app.ts --compile --bytecode --format=esm --outfile myapp ``` The new `--compile-jit-policy ` flag (`compile: { jitPolicy: n }` in `Bun.build`) scales JIT tier-up thresholds. Run-once startup code stays in the interpreter longer. Call `Bun.unsafe.setJITPolicy(1)` once your app is interactive: ```ts await renderFirstScreen(); Bun.unsafe.setJITPolicy(1); // back to the normal JIT policy ``` - `--no-optimize-bytecode` / `optimize: { bytecode: false }` skips the build-time bytecode optimizer. ## Other improvements - Fixed: `crypto.randomInt()` was about 20x slower per call since Bun 1.4.0. It takes 34 ns instead of 760 ns, on par with Node.js. - Fixed: small zstd calls were up to 3.7x slower in x64 virtual machines since Bun v1.4.0. `Bun.zstdDecompressSync` on a 1 KB input takes 1.38 µs instead of 5.11 µs. - Fixed: `node:zlib` calls on small inputs were slower since Bun v1.4.0. `gunzipSync` with a 1 KB result takes 2.97 µs instead of 4.99 µs, and 64 MB through gzip streams takes 131 ms instead of 166 ms. - Fixed: `Bun.color()` got slower in Bun v1.4.0, and this recovers most of that. A call takes 208 ns instead of 692 ns, and 432 ns instead of 17,793 ns when 8 Workers call it at once. - Improved: a short `transpiler.transformSync()` call takes 550 ns instead of 1,236 ns, and 2,290 ns instead of 15,246 ns when 8 Workers call it at once. - Improved: `vm.runInContext()` and `vm.runInNewContext()` are about 30% faster per call (2.5 µs to 1.7 µs). `new vm.Script(src, {})` is about 2x faster. This recovers most of a 1.4.0 regression. - Improved: `Bun.serve` answers pipelined HTTP/1.1 requests with one `send()` for the whole batch instead of about 14 syscalls per response. This fixes a regression from Bun v1.2.6. - Improved: `Object.keys(require.cache)` and `key in require.cache` no longer leak a namespace object per loaded ES module. Listing 2,000 modules dropped from 38 ms to 2.6 ms. - Improved: `Bun.markdown.render()` no longer takes quadratic time on deeply nested lists or emphasis when no callback is registered for the nested element. In Bun v1.4.2, 300 KB of nested lists took 99.5 s. - Improved: `Bun.gc(true)` and `gc()` return freed memory to the OS before returning, so RSS drops right away instead of after a delay. This holds even when a background purge is in progress, and memory freed during a purge no longer stays resident until the event loop goes idle. - Improved: Bun's mimalloc fork is now slightly smarter about when to give freed memory back to the operating system. Echoing a 512 KiB JSON body, Elysia takes 388 page faults per request instead of 574, and Express 523 instead of 762. - Improved: threads that are idle after `WebAssembly.compile()`, or blocked in `Atomics.wait()` or `Bun.sleepSync()`, give freed memory back to the OS after about 100 ms. A thread blocked for one second after freeing most of its heap held 115 MB instead of 424 MB. - Improved: on macOS, `process.memoryUsage().rss` now reports the physical memory footprint that Activity Monitor shows, and `process.resourceUsage().maxRSS` reports its peak. - Improved: long-running `bun build --compile` apps on Linux keep less of Bun's own code resident in memory. Bun's linker order file now also traces app-shaped workloads. - Improved: on Windows, `Bun.secrets.set()` takes `persist: "local"` to keep a credential on the current computer. By default (`"enterprise"`) it roams with the user's account. - Improved: updated SQLite to 3.53.4, libarchive to 3.8.9, brotli to 1.2.0, lsquic to 4.9.4 and libjpeg-turbo to 3.2.0. Chunked HTTP bodies with bare-LF chunk line endings are now rejected, as in llhttp. - Improved: updated the bundled root certificates to NSS 3.128 (Firefox 156). This adds SECOM and Telia TLS roots and removes Entrust Root Certification Authority, ePKI, Atos TrustedRoot 2011, and SecureSign Root CA12. - Improved: the `oven/bun:alpine` Docker image is now based on Alpine 3.24, matching the libstdc++ the musl build links against. - Improved: `bun test --coverage-reporter=lcov` now implies `--coverage`. Before, it ran the tests and wrote no report. ## Bugfixes ### Security - Hardened: `fetch`, `WebSocket`, `Bun.connect`, `Bun.RedisClient` and `Bun.SQL` verify the server during the TLS handshake instead of after it, like curl and Go. Error codes are unchanged. - Hardened: TLS certificate name matching in `tls.connect`, `tls.checkServerIdentity`, `https`, `fetch` and `Bun.connect` only accepts valid host names and canonical IP addresses (CVE-2026-48618). - Hardened: certificate verification in `node:tls` and `Bun.listen` when a connection closes during the TLS handshake. - Hardened: certificate checks in `node:tls`, `https.Agent` and `fetch()` when a TLS session or pooled connection is reused. `fetch()` rejects a `tls.checkServerIdentity` that isn't a function or that returns a truthy value, as in Node. - Hardened: `Bun.SQL` treats `tls: Bun.file("ca.pem")` (or `ssl:`) like `tls: { ca: Bun.file("ca.pem") }` and uses `verify-full`. - Hardened: `node:http2` servers rate-limit stream resets (CVE-2023-44487, CVE-2025-8671). `streamResetBurst` and `streamResetRate` take effect, matching Node. - Hardened: `Bun.serve` follows RFC 9112 more strictly after `Connection: close`. - Hardened: rare scenario when precise conditions are met that can cause `req.url` and `req.headers` to return incorrect values on aborted requests in `Bun.serve()`. - Hardened: TLS `Bun.serve()` servers apply the idle timeout to connections that never finish the handshake. - Hardened: `fetch()` validates chunked transfer encoding in responses more strictly, like Node. - Hardened: `fetch("file://host/path")` rejects with `ERR_INVALID_FILE_URL_HOST` unless the host is empty or `localhost`. - Hardened: `fetch()` rejects when your code passes a `Content-Length` header that doesn't match the `ReadableStream` body it sends. - Hardened: `fetch()` and `node:http` agents terminate an idle keep-alive connection that received unexpected data, matching Node.js. - Hardened: `fetch()` against servers that close or reset a TLS connection at unexpected times. This fixes three rare crashes. - Hardened: `bun install` parses registry and tarball URLs more strictly before attaching credentials. - Hardened: `bun install` against malformed `bin` fields in a `package.json` or registry manifest. - Hardened: `Bun.Archive#extract()`, `bun create` and `bun install` of `github:` dependencies against malformed tar archives. - Hardened: `v8.deserialize()` and IPC with `serialization: "advanced"` against crafted records. - Hardened: UDP socket `addMembership()`, `dropMembership()` and their source-specific variants against arguments with side effects. ### Node.js compatibility improvements #### `node:http` - Fixed: after `req.pause()` in a `node:http` server, a small body was not received until `req.resume()`, so `req.complete` stayed `false` and `req.readableLength` stayed `0` while paused. - Fixed: in a `node:http` server, `res.end()` before the request body had arrived made `req` emit `'end'` at once and dropped the rest of the body. A handler that read the body first was unaffected. - Fixed: in a `node:http` server, a synchronous `res.destroy()` in the `'request'` listener or a `'data'` listener, while the request body was still arriving, made `req` emit `'end'` with `req.complete === true` instead of `'aborted'` and `ECONNRESET`. - Fixed: `'finish'` and the `res.end()` callback on a `node:http` response fired before the last bytes left the socket. This needed a response too large for the kernel's socket buffer and a client that was slow to read it. - Fixed: a `node:http` response never emitted `'drain'` when `res.write()` had returned `false` and other code, such as a heartbeat timer, called `res.write()` again just as the client caught up. A `stream.pipe(res)` on that response then hung. - Fixed: a `node:http` server never answered a pipelined request when part of its body arrived after the previous response had ended. - Fixed: `server.close()` on a `node:http` server called back once in-flight responses finished, while their keep-alive connections were still open and serving requests. `closeAllConnections()` after `close()` did nothing, so an open connection kept the process alive. - Fixed: `server.closeAllConnections()` also stopped the listener and destroyed tunnels and WebSockets. - Fixed: writes to a `node:http` `'upgrade'` or `'connect'` socket stayed buffered until `socket.end()` when the same keep-alive connection had already served a request. The npm `ws` package stalled this way. Fresh connections were unaffected. - Fixed: CONNECT and Upgrade tunnel sockets kept reading while paused. - Fixed: a `node:http` `'connect'` or `'upgrade'` listener that called `socket.end()` missed part of the data the client had sent right behind the request. This needed request headers that arrived in more than one read, with more than 17 KB of data behind them. - Fixed: a `node:http` server dropped the body of a HEAD or TRACE request that declared one with `Content-Length`. - Fixed: `Proxy-Connection: close` now closes the connection, like `Connection: close`. - Fixed: HTTP/1.0 requests with an `Expect` header get a plain `'request'`, not `100 Continue`. - Fixed: servers fed a socket through `server.emit("connection", duplex)` or http2's `allowHTTP1` fallback threw `ERR_HTTP_SOCKET_ASSIGNED` on pipelined or fast keep-alive requests. - Fixed: `req.setTimeout()` never fired when a pipelined request's body stalled behind a pending response. The server closed the socket instead. - Fixed: `node:http` `server.close()` never called back when a request body finished arriving while the `IncomingMessage` was paused, the response ended later, and the same keep-alive connection then served another request. - Fixed: calling `listen()` on a `node:http` server that was already listening leaked the first listener and kept the process alive after `close()`. It now throws `ERR_SERVER_ALREADY_LISTEN`, like Node. - Fixed: `node:http` servers emitted `'clientError'` repeatedly for the same stalled request (eventually triggering `MaxListenersExceededWarning`) when the listener didn't destroy the socket after a `headersTimeout` or `requestTimeout`. - Fixed: in `node:http` servers, `req.socket` emitted only `'close'` when the client closed the connection, never `'end'` for a FIN or `'error'` (`ECONNRESET`) for a reset. - Fixed: `req.socket.setKeepAlive()` and `req.socket.resetAndDestroy()` in a `node:http` server returned `undefined` instead of the socket, so chaining threw. - Fixed: a `node:http` server that called `res.detachSocket()` on an unfinished response could, in rare cases, crash on a later use of that response, or never exit, after the client disconnected. Regression since v1.4.0. - Fixed: `node:http` and `node:https` proxy errors (`ERR_PROXY_TUNNEL`, `ERR_PROXY_INVALID_CONFIG`) included the username and password from the proxy URL. - Fixed: a proxied `node:https` request (`new https.Agent({ proxyEnv })`, `NODE_USE_ENV_PROXY=1`) emitted `'close'` but never `'error'` (`ECONNRESET`) when the connection ended after the proxy accepted `CONNECT` but before the TLS handshake finished. #### `node:http2` - Fixed: on Linux, `http2.connect()` to a closed port reported `ECONNRESET` instead of `ECONNREFUSED`. With no `'error'` listener, the failure was silently swallowed. Regression since v1.4.0. - Fixed: a `node:http2` request with `[http2.sensitiveHeaders]` also sent a literal `nodejs.http2.sensitiveheaders` header that listed those header names. `Bun.spawn` env and macros also turned Symbol keys into string keys. - Fixed: `node:http2` ALTSVC and ORIGIN frames used UTF-8 instead of latin-1, so a value containing bytes 0x80 to 0xFF read differently on a Node.js peer. ASCII values were unaffected. - Fixed: `http2.connect()`, `createServer()` and `createSecureServer()` accepted invalid options that Node rejects, such as a non-boolean `strictSingleValueFields`. - Fixed: `ClientHttp2Stream.close(code)` emitted `error` for `NGHTTP2_CANCEL`, and `end` before `error` for other error codes. - Fixed: `session.originSet` threw after `destroy()` on a TLS session that had never read it. It now returns `undefined`, like Node. #### `node:tls` - Fixed: `tls.Server#setSecureContext()` had no effect on a server that was already listening. - Fixed: `tls.Server#addContext()` and `Bun.serve({ tls: [{ serverName }] })` served the default certificate for a hostname with an unusually large number of labels. An `addContext()` wildcard also did not cover the hostname passed to `listen()`. - Fixed: client-side `new tls.TLSSocket(socket)` (STARTTLS) never started a handshake. `write()` threw a `TypeError` and `_start()` threw `ERR_MISSING_ARGS`. The `mysql` package connects this way when `ssl` is set. - Fixed: after `tls.connect({ socket })`, `'data'` listeners left on the plain socket kept firing with the encrypted bytes. A STARTTLS listener that called `tls.connect({ socket })` on every chunk got `Invalid socket` from the second call. - Fixed: a TLS socket that wraps a `net.Socket` ignored the wrapped socket's `allowHalfOpen`. A STARTTLS server created with `net.createServer({ allowHalfOpen: true })` could not reply after the client ended its side. - Fixed: a `net.Socket` wrapped by `new tls.TLSSocket(socket)` or `tls.connect({ socket })` emitted its own `'error'` on a peer reset, and `'end'` and `'finish'` on `tlsSocket.destroy(err)`, on top of the TLS socket's events. Node emits only `'close'` on the wrapped socket. - Fixed: destroying a `tls.connect({ socket })` client in the same tick it was created left the wrapped `net.Socket` open, with no FIN sent, if that socket still had unflushed writes. - Fixed: when a `node:tls` socket ran over a plain `stream.Duplex` (not a `net.Socket`), destroying the `Duplex` with an error threw an uncaught exception instead of emitting `'error'` on the TLS socket. An `https.request` over such a socket exited the process. - Fixed: a server-side `tls.TLSSocket` over a `Duplex` emitted `ECONNRESET` and no `'close'` when the `Duplex` was destroyed before the handshake finished. If it was destroyed in the same tick as the wrap, the TLS socket emitted nothing. - Fixed: in an uncommon configuration, a `node:tls` server over a `Duplex` whose `ALPNCallback` writes to the socket, the server could crash during the handshake. - Fixed: `end()` on a `node:tls` socket over a `Duplex` never ended the `Duplex` (the peer saw no FIN) if the peer stalled mid-handshake or never answered the TLS close. - Fixed: `tls.TLSSocket` `end()` and `destroySoon()` sent no FIN when the peer never answered the TLS handshake, so the socket never emitted `'close'`. - Fixed: an accepted `node:tls` socket whose peer reset the connection during a large write could emit only `'end'`, never `'error'` or `'close'`, so `server.close()` never completed. This was seen on Linux and depended on timing. - Fixed: a `tls.connect()` or `node:https` client that wrote before a TLS 1.3 handshake finished could get `ECONNRESET` instead of the reply. This needed a server without `noDelay` that reset the connection a few milliseconds after replying. #### `node:net` and `node:dns` - Fixed: a `node:net` socket could drop or resend bytes after a partial `writev()`. This needed a peer that had stopped reading, data already buffered for it, and a new write that the kernel accepted only part of. - Fixed: `net.Socket#write()` returned `true` when the send failed immediately (`ECONNRESET`, `EPIPE`, or a closed handle). It now returns `false` and sets `socket.errored`, matching Node. - Fixed: `node:net` routed an exception thrown in a socket `'data'` or server `'connection'` listener to the socket's `'error'` event and closed the socket, instead of `uncaughtException` like Node. - Fixed: a `node:net` or `node:tls` socket was never garbage collected if it was destroyed before its connection attempt started (in the same tick as `connect()`, or during the DNS lookup), or if its DNS lookup failed. - Fixed: `new net.Socket({ fd, readable: false, writable: true })` ended and closed the fd one tick after construction, so later writes failed with `EPIPE`. - Fixed: `fetch()`, `Bun.connect()` and `dns.lookup()` (on macOS and Windows, or with the `system`/`libc` backend) reported a temporary DNS failure (SERVFAIL or every nameserver timing out) as `ETIMEOUT` instead of `EAI_AGAIN`, so retry logic keyed on `EAI_AGAIN` never fired. #### `node:child_process` - Fixed: on Linux and macOS, with `child_process.spawn()` and an `"ipc"` stdio slot, a non-JS child (e.g. Python) that wrote a message larger than the socket buffer in one `write()` got a short write, and the message never arrived. - Fixed: `child_process.spawnSync()` of a command that can't be spawned returned `status: undefined`, `pid: undefined` and `output: [null, null, null]`. It now returns `status: null`, `pid: 0` and `output: null`, like Node. - Fixed: `child.stdin.end(cb)` and `tty.WriteStream#end()` called with no data fired `cb` and `'finish'` while earlier writes still waited on a full pipe. A parent that exited in `cb` truncated the child's input. `end(chunk, cb)` was not affected. - Fixed: `child_process.spawn()` now throws `ERR_INVALID_ARG_VALUE` when `stdio` holds a `tls.TLSSocket`, like Node.js. - Fixed: calling `destroy()` inside a `'data'` listener on `child.stdout`, `child.stderr`, or a `Readable.fromWeb()` stream emitted one more `'data'` (and sometimes `'end'`). `exec()` with `maxBuffer` could overshoot the limit by a chunk. Regression in v1.4.0. #### `node:module` - Fixed: `require()` and `require.resolve()` crashed when `Module._resolveFilename` was set to a non-function. They now throw a `TypeError`, like Node. - Fixed: `require()` of an ES module crashed when code had replaced `Module._resolveFilename` with its own function, and that function returned a path that was not normalized (a symlink, or one containing `/./`, `/../` or `//`). - Fixed: the second `require()` of an ES module threw if a `Module._extensions` handler had called the original loader and caught the module's error. The module was dropped from `require.cache`. - Fixed: Bun crashed when a preload set `Module.runMain` to a non-function such as `{}` or a string. An override that threw printed only `Error occurred loading entry point: JSError`, without the error. #### `node:vm` - Fixed: when the host passed its `File` or `fs.Stats` class into a `node:vm` context, `class Upload extends File {}` there crashed on `new Upload(...)`. A host `PerformanceObserver` whose callback was created in a context crashed when it delivered entries. - Fixed: `vm.runInContext()`, `vm.runInNewContext()` and the matching `vm.Script` methods crashed instead of throwing a `TypeError` when an option such as `displayErrors` was given a null-prototype object that had a custom `util.inspect` function. - Fixed: `node:vm` aborted the process, even inside `try`/`catch`, when text it built from JS, such as `compileFunction()` parameters or a thrown error's `stack`, passed the maximum string length of 2^31 - 1 characters. - Fixed: a `vm.Script`, `vm.compileFunction` or `vm.SourceTextModule` kept its context alive for the life of the process when its `importModuleDynamically` callback could reach that context (such as a closure over the sandbox) and the code left a function on it. - Fixed: in a `node:vm` context, the `TypeError` thrown when `Object.defineProperty` on the global failed was created in the host realm instead of the context's realm. #### `node:fs` - Fixed: on Linux and macOS, `node:fs` opened files without `O_CLOEXEC`. Child processes forked by native code, such as `node-pty` or an addon calling `system()`, inherited those descriptors. Children of `Bun.spawn` and `node:child_process` did not. - Fixed: inside a `node:fs` callback, a microtask the callback queued ran before a `process.nextTick()` it queued. The order now matches Node. - Fixed: `fs.readSync()` and `fs.read()` threw `ERR_OUT_OF_RANGE` instead of Node's `ERR_INVALID_ARG_TYPE` when `buffer` was not a buffer and `offset` was invalid. #### `node:util` - Fixed: `util.format('%s', value)` printed the `util.inspect()` output (such as ``) for `Buffer`, `URL`, and `URLSearchParams`. It now prints their `toString()` result, as Node does. - Fixed: every garbage-collected `MIMEType` from `node:util` leaked its `type` and `subtype` strings. That was about 57 bytes per instance for a `text/html` type with a `charset` parameter. - Fixed: `util.aborted()` invoked a user-replaced `Function.prototype.bind` on its internal abort listener. - Fixed: after a few hundred `util.promisify()` calls, `util.promisify(setTimeout)` could return the promise version of `setImmediate` or `setInterval` if that timer was promisified first, so `await sleep(300)` resolved at once. Regression in v1.4.1. #### `node:crypto` - Fixed: in `node:crypto`, `hash.update()` after `hash.end()`, which throws in Node.js, hung forever on `sha3-*` hashes. `hash.end()` after `digest()`, as when `pipe()` ends a hash whose `digest()` was already called, emitted `ERR_CRYPTO_HASH_FINALIZED` instead of the digest. - Fixed: `crypto.hkdfSync()` and `crypto.hkdf()` returned an empty `ArrayBuffer` for a `keylen` of 0 instead of failing with "HKDF derivation failed", as Node.js does. #### `node:buffer` - Fixed: `buffer.transcode()` aborted the process, even inside `try`/`catch`, when its output needed 2 GiB or more. - Fixed: `buf.utf8Write(123)`, `buf.hexWrite(123)` and the other per-encoding `Buffer` write methods wrote the string form of a non-string value. They now throw `ERR_INVALID_ARG_TYPE`, like Node.js. #### Native addons - Fixed: when the main thread or a Worker exited naturally, a native addon's N-API finalizers and cleanup hooks could still call into JavaScript, and that JavaScript could call a second addon that was already torn down. These calls now return `napi_cannot_run_js`, like Node.js. - Fixed: native addons that call `v8::Function::GetScriptOrigin()`, such as `@newrelic/fn-inspect`, failed to load on Linux and crashed on macOS. #### Other modules - Fixed: `node:wasi` `poll_oneoff` threw `TypeError: Invalid mix of BigInt and other type in subtraction` on any clock wait with a positive timeout, so a WASI `sleep()` failed. - Fixed: `node:wasi` `fd_pread` reported twice the bytes read whenever a read filled its buffer. - Fixed: `require("cluster")` threw `cluster._setupWorker is not a function` when a script set `process.env.NODE_UNIQUE_ID` itself after `node:net` had loaded. - Fixed: `node:dns` and `AsyncLocalStorage.bind()` argument errors read `The "undefined" argument must be of type ...` instead of naming the argument. - Fixed: response bodies from an installed copy of Undici could stay pending instead of rejecting after a forced socket close, because `node:stream`'s `isReadable()` returned `null` for web `ReadableStream`s. - Fixed: `for await (const line of rl)` over `node:readline` threw `ERR_USE_AFTER_CLOSE` and dropped the last line when the input ended with a single chunk of 1,026 or more lines. This hit `Readable.from([text])` and HTTP responses, not files, stdin or child process output. Regression in v1.4.0. - Fixed: in `node:quic`, `sendHeaders()` on a stream opened before the handshake finished was not sent until the client wrote a body or ended the stream. - Fixed: `url.parse()` and `url.resolve()` crashed instead of rethrowing when they were passed an object instead of a string and a getter on that object (like `constructor`) threw a primitive value. - Fixed: `class Sub extends StringDecoder {}` returned the class itself from `new Sub()` instead of an instance, so `write()` was undefined. - Fixed: `process.exit()` called a replaced `process.reallyExit` with the wrong `this` (now `process`). It also threw a `TypeError` with an empty message when `process.reallyExit` was not a function. - Fixed: seven Node.js error codes had a wrong `.message` that now matches Node.js. For example, `ERR_HTTP_TRAILER_INVALID` read `undefined` and `ERR_INVALID_URL_SCHEME` read `file`. - Fixed: `node-fetch`'s `fetch(url, { body })` never settled when an old-style `Stream` body that isn't a `Readable` (such as `form-data`) emitted `"error"` before `"end"`. It now rejects with that error. - Fixed: `node-fetch`'s `new Response(stream)` threw for an old-style `Stream` that isn't a `Readable`. This broke `node-fetch-cache`. ### Bun APIs - Fixed: `Bun.serve` dropped WebSocket frames that a client sent without waiting for the `101` response, when they arrived in the same TCP read as the upgrade request. Browsers wait for the `101`, so they were not affected. - Fixed: on Linux, a `Bun.serve` response serving a file of 1 MB or more could send file bytes before the end of its headers. This needed response headers too large for the kernel's send buffer (the repro used a 16 MB header). - Fixed: in a `Bun.serve` server with `http2: true` or `http3: true`, some requests with a streamed response body were never released, so `pendingRequests` stayed above zero and a graceful `server.stop()` never resolved. Both options are off by default. - Fixed: in `Bun.serve` with `http3: true`, calling `server.stop()` from inside a request handler spun at 100% CPU if that connection had already served a request. Calling `stop(true)` from a handler left clients waiting 10 to 30 seconds for their idle timeout. - Fixed: in `Bun.serve` with `http2: true`, the tail of a streamed body under 256 bytes was sent twice when the client's flow-control window cut it off more than once, causing `PROTOCOL_ERROR`. - Fixed: in `Bun.serve({ http3: true })`, a request header value that a client sent with leading or trailing whitespace reached the handler untrimmed. `req.headers.get()` returned `" v\t"` where HTTP/1.1 gave `"v"`. - Fixed: with `Bun.serve({ tls })`, `ws.terminate()` waited for the peer's TLS shutdown reply instead of closing at once. If the peer had stopped reading, the `close` handler did not run until the idle timeout, and `message()` could still fire. - Fixed: `Bun.serve` crashed with a stack overflow when a handler called `response.text()` on a `fetch()` Response without awaiting it, then returned that Response before its body arrived. It now responds with a 500 via `error()`. - Fixed: `Bun.serve()` responded `200` with an empty body when a second `Response` reused a `ReadableStream` an earlier response already sent. It now errors. - Fixed: `Response.clone()` on a body from an unread `Bun.file().stream()` dropped the MIME type, so `Bun.serve` sent no `Content-Type` for the clone. - Fixed: a `Bun.serve` handler that called `req.clone()` on a request with a body and then read neither copy leaked about 7 KB of memory per request. - Fixed: a `Bun.serve` response with a `type: "direct"` stream sent an empty body when `pull()` wrote and then called `controller.close()` in the same tick. `cancel()` also ran after every completed response. - Fixed: in a `Bun.serve` direct stream, a synchronous `pull()` that ended a chunked response (for example `flush()` then `end()`) and then threw in the same call wrote the last chunk twice. Strict clients then failed to parse the next keep-alive response. - Fixed: in a `Bun.serve` direct stream, an async `pull()` that called `end()` after an `await` and then never returned kept its request pending, so a graceful `server.stop()` never resolved. - Fixed: in a `Bun.serve` direct stream, a `flush(true)` promise never settled (and leaked) if `end()` was called while the socket was still backpressured. - Fixed: calling `server.ref()` after `await server.stop()` completed kept the process alive forever. - Fixed: `Bun.spawn`, `Bun.spawnSync` and `node:child_process` returned truncated data with no error when the kernel failed a read or write on a stdio pipe with an errno like `EIO` or `ENOBUFS`. They now report the error. Found by fault injection. - Fixed: on macOS and Linux, `spawnSync` or `execFileSync` could spin at 100% CPU and never return after a garbage collection during an earlier `Bun.spawnSync` freed a stream such as a previous test file's `process.stderr`. Users hit this in large `bun test --isolate` suites. - Fixed: after user code closed fd 0, 1 or 2 (e.g. `fs.closeSync(1)`), `Bun.spawn` could reuse that number for its own pipes. `proc.stdout.text()` then hung if fds 0 and 1 were both closed, and on Linux a child with `stdout: "inherit"` could overwrite a `Blob` of 8 MiB or more. - Fixed: on macOS, `subprocess.signalCode` and `subprocess.kill()` used Linux signal numbers, so a child killed by SIGBUS reported `"SIGUSR1"` and `kill("SIGUSR1")` sent SIGBUS. Signals numbered the same on both systems, like SIGTERM, SIGKILL and SIGINT, were not affected. - Fixed: on Linux, when the process hit its open file limit right after starting a child, `Bun.spawn` and `child_process.spawn` blocked until that child exited. A child waiting on a stdin pipe never did, which froze the process. They now fail with `EMFILE`. - Fixed: `Bun.spawnSync` crashed the process when it ran out of file descriptors (handles on Windows) while creating its event loop on the first call. It now throws `EMFILE`. - Fixed: on macOS and Linux, when a `Bun.spawn({ terminal })` child exited with `terminal.write()` input still queued, the `Bun.Terminal` and its three pty file descriptors were never released and the process used CPU while idle. This was a regression in v1.4.0. - Fixed: on Windows, calling `terminal.write()` after the child exited leaked the `Bun.Terminal` and its callbacks, a regression in v1.4.0. - Fixed: on Linux and macOS, the process never exited when code held a reader on `Bun.spawn` stdout or `Bun.stdin.stream()`, stopped calling `read()` while more than 16 KB of output was still unread, and the other end then closed. - Fixed: a pipe-backed `FileSink` (`Bun.stdout.writer()`, `Bun.spawn` `stdin`) lost buffered data when a write was larger than the pipe could accept at once and `end()` was then called without a top-level `await`. The process exited before the reader drained the pipe. - Fixed: `Bun.file().stream()` hung instead of erroring when the underlying `read()` failed with an error like `EIO`, for example on `/proc/self/mem`. After such an error on a pty or non-blocking pipe, the process never exited. - Fixed: on macOS, `await Bun.write(dest, Bun.file(src))` resolved to `0` instead of the byte count when `dest` already existed or was on another volume. The file itself was copied in full. - Fixed: `Bun.file(path).exists()` kept returning `false` after the file was created, if an earlier `exists()` or `size` on the same `Bun.file()` had found no file. - Fixed: an `HTMLRewriter` was never garbage collected when one of its handlers referenced the rewriter or the transformed `Response`. - Fixed: `HTMLRewriter` leaked the output `Response` when an `element.onEndTag()` callback referenced it and a handler threw or the output was cancelled before that end tag. - Fixed: when `HTMLRewriter.transform()` read a `type: "direct"` stream body and a handler threw, the output was cancelled, or the client disconnected, the stream's `cancel()` received `undefined` and its next `write()` threw. `cancel()` now receives the reason and `write()` returns `0`. - Fixed: `Bun.Image` threw `ERR_IMAGE_DECODE_FAILED` for slightly damaged JPEGs (stray bytes, a missing end marker, truncated data) that libjpeg-turbo can decode with only a warning. - Fixed: in `Bun.markdown` with `wikiLinks: true`, a `*`, `_` or `~` inside a `[[target|label]]` target paired with one outside the link, leaving an unclosed ``, `` or ``. - Fixed: in `Bun.markdown`, a `*` inside a reference link's label could leave an unclosed `` when the link was followed by `(<` with no closing `>`, as in `*[a*]( - Fixed: `YAML.stringify()` with an indent argument left a trailing space after keys, put empty `[]` and `{}` on their own line, and misaligned nested sequences at indent widths other than 2. - Fixed: `YAML.stringify()` could write a `*alias` in place of an unrelated object or array. This needed getters or Proxy traps that returned a new object on each read, and a garbage collection during the call. - Fixed: in a `Worker`, `Bun.TOML.stringify()` crashed instead of throwing `RangeError: Maximum call stack size exceeded` on an object nested about 9,500 levels deep, just under the depth limit. Deeper objects already threw. - Fixed: `Bun.wrapAnsi()` aborted the process instead of throwing a `RangeError` when an input line wrapped into tens of millions of rows or one row approached 2 GB. - Fixed: `Bun.stripANSI()` aborted the process on a non-Latin-1 string of 2^30 or more characters that contained an escape sequence, as did `Bun.sliceAnsi()` on about 78 million escape sequences in a row. - Fixed: `Bun.indexOfLine()` could miss a line break in input that is not valid UTF-8, so `for await (const line of console)` merged two lines. - Fixed: on Linux, `Bun.Glob` scans with `*`, `?` or `[...]` could miss file names that are not valid UTF-8, such as names from a Latin-1 archive. `bun pm pack` could also pack such a file that `.npmignore` excludes. - Fixed: `new Bun.FileSystemRouter()` panicked or returned truncated route names for nested files when `dir` was an absolute path containing `..`, such as `import.meta.dir + "/../pages"`. - Fixed: `cc()` from `bun:ffi` could crash or hang when several Workers made their first `cc()` call at the same time. - Fixed: subclassing `Bun.Cookie`, `Bun.CookieMap`, `crypto.ECDH`, `crypto.DiffieHellman`, `dns.Resolver` or `$.Shell` returned an instance of the base class, so `instanceof` and subclass methods broke. - Fixed: `X509Certificate`, `crypto.hkdf`, `bun:sqlite`, and `Bun.CookieMap` aborted the process when given a non-ASCII string of 2^30 or more characters. They now throw a `RangeError` or report no match. ### Web APIs #### `fetch` - Fixed: on macOS, `fetch()`, sockets and `dns.lookup()` failed with `ENOTFOUND` for split-DNS names, like a host only a VPN's resolver knows while iCloud Private Relay is on. - Fixed: a `fetch()` body stream (`res.body`) or `s3file.stream()` that code created, never read and dropped kept its connection if the server stopped sending mid-body. With 256 of these open at once, later `fetch()` calls stayed pending. - Fixed: a regression in 1.4.1 where, after more than 64 concurrent `fetch()` requests to one keep-alive origin finished, the surplus idle connections were closed with an RST, so servers logged `ECONNRESET`. The responses themselves were not affected. - Fixed: a regression in 1.4.0 where `fetch()` leaked an ASCII string `body` when it rejected before sending, such as on an invalid header name or a `GET` with a body. - Fixed: `fetch()` sent the URL fragment to the server in the request line when the fragment contained a `?` and no query string came before the `#`, as in `/#/users?id=1`. - Fixed: `delete process.env.HTTPS_PROXY` (or reassigning it after a delete) had no effect on later `fetch()` calls. - Fixed: `fetch(url, { unix })` sent a proxy-form request down the Unix socket when `HTTP_PROXY` was set. - Fixed: a streamed `fetch()` response with `Content-Encoding: br` or `zstd` delivered only the first 4096 bytes of a larger flushed chunk, holding the rest until the next compressed chunk arrived. - Fixed: a compressed `fetch()` body read through a stream reader over HTTP/1.1 was decompressed as fast as it arrived, not as fast as it was read. With a slow reader and an unusually compressible body, memory could grow by hundreds of MB. - Fixed: `fetch()` rejected a valid `Content-Encoding: deflate` response with `ZlibError` when the server compressed with a zlib window smaller than 32 KB, or when the first read held only one byte of the body. - Fixed: after a `fetch()` was aborted mid-body, native readers of `res.body` such as `new Response(res.body).text()` or `Bun.write()` got a generic `AbortError` or an empty body instead of `signal.reason`. - Fixed: a stream taken from a `fetch()` body, `req.body`, `S3File.stream()` or `HTMLRewriter` output while the transfer was running, but first read after it had failed, ended cleanly with 0 bytes instead of rejecting. In rare cases since 1.4.0, a partly read stream crashed. - Fixed: a memory leak where a `fetch()` `Response` and its `AbortSignal` were never garbage collected if an `abort` listener on the signal referenced the response. - Fixed: after `req.clone()` in `Bun.serve` or `res.clone()` on a `fetch()` response, a reader on the original's `body` stream ended with `done: true` instead of rejecting when the body failed mid-stream. `text()` and the clone already rejected. - Fixed: `arrayBuffer()` and `bytes()` on a `fetch()` response or `Response` whose body exceeded 4 GiB aborted the process instead of rejecting with `RangeError: Out of memory`. - Fixed: over HTTP/2 and HTTP/3, `fetch()` kept leading and trailing whitespace on a response header value when the server sent it, which the HTTP/2 spec forbids. A padded `Location` header failed to redirect. - Fixed: `fetch()` with `protocol: "http3"` crashed when the QUIC connection closed before the response headers arrived and the automatic retry could not open a new connection at all, such as when no address for the host was reachable. - Fixed: aborting an HTTP/3 `fetch()` upload made the server treat the truncated body as complete. If the request declared a `content-length`, the server closed the connection and the next upload to that origin could reject with `HTTP3StreamReset`. - Fixed: HTTP/3 `fetch()` and `Bun.serve({ http3: true })` spun at 100% CPU when the kernel kept refusing UDP sends, such as under a firewall DROP rule or a low egress MTU. #### `WebSocket` - Fixed: the `WebSocket` client reported close code `1005` or a `1002` protocol error when the server's Close frame was split across two TCP reads within its first three bytes. - Fixed: a `wss://` WebSocket through an HTTP CONNECT proxy reported close code 1006 "Failed to write" instead of the server's close code when the server ended TLS right behind its Close frame, as `ws.close()` in `Bun.serve` does. - Fixed: a `wss://` WebSocket to an IP address such as `127.0.0.1`, or through an HTTPS proxy at an IP address, closed with code 1006 when a TLS 1.2 server renegotiated (regression in 1.4.1). #### Streams - Fixed: `controller.write()` in a `type: "direct"` `ReadableStream` never waited for a slow reader using `getReader()`, `for await` or `pipeTo()`. Once unread bytes reach `highWaterMark` (64 KiB by default), it now returns a promise that resolves on the next read. - Fixed: a direct stream's `cancel(reason)` was never called on `reader.cancel()`, `stream.cancel()`, or a `break` out of `for await`. - Fixed: in a direct stream, a `write()` made after `end()` or `close()` inside `pull()` was still delivered to the reader. - Fixed: `bytes()` and `arrayBuffer()` hung on a direct stream whose async `pull()` called `controller.end()` and never returned. - Fixed: `Duplex.fromWeb` dropped the last chunk of a `type: "direct"` `ReadableStream` when `pull()` called `controller.error()` or threw right after flushing that chunk. Only the `error` event was emitted. - Fixed: an async-iterable body (`new Response(asyncGen())`, a `fetch` upload, a `Bun.serve` response) was silently truncated or hung when the generator threw an error with code `ERR_INVALID_THIS`, instead of failing the stream. - Fixed: `new Response(asyncIterable)` kept pulling the iterator after its consumer had stopped early, through `reader.cancel()`, a `break` out of `for await`, a failed `pipeTo()`, or a `Bun.write()` that hit `ENOSPC`. It now calls the iterator's `return()`, so `finally` blocks run. - Fixed: `finished(stream)` from `node:stream/promises` never settled for a `fetch()` body or `Bun.file()` stream consumed natively (by `Bun.write()`, a `fetch()` request body, `Bun.serve()`, spawn stdin, or S3). The stream stayed `readable`. - Fixed: for a `Response` body backed by a string, `Blob`, typed array or file, reading `res.body` and then calling `arrayBuffer()`, `bytes()`, `blob()`, `json()` or `formData()` left the stream `readable`, so `finished(body)` from `node:stream/promises` never settled. - Fixed: a `res.body` stream taken before `await res.text()` (or `json()`, `blob()`, etc.) was left unlocked afterwards and `getReader()` still worked, unlike undici and browsers. - Fixed: reading `blob.slice(start, end).stream()` with `.text()`, `.bytes()`, `.json()` or `Bun.readableStreamToText()` returned the whole parent `Blob` if the parent and the slice had already been garbage-collected. - Fixed: `ReadableStream` `cancel()`, `pipeTo()` and `pipeThrough()` on a locked stream threw a `TypeError` without `code: "ERR_INVALID_STATE"`, a regression from 1.3. - Fixed: web streams aborted the process instead of throwing `RangeError: Out of memory` when a queue or buffer hit its size limit, such as 67 million chunks queued and not yet read, or a single 2 GiB chunk (since 1.4.0). #### Other - Fixed: `postMessage()` detached the `ArrayBuffer`s in its transfer list even when it threw `DataCloneError` because a getter in the message closed a transferred `MessagePort`. ### TLS - Fixed: `fetch()`, `WebSocket`, and `Bun.SQL` with `sslmode=verify-full` failed certificate verification when connecting to an IPv6 literal like `https://[::1]:3000`, even when the cert had a matching IP SAN. `fetch()` rejected with `ERR_TLS_CERT_ALTNAME_INVALID`. - Fixed: a `Bun.connect` TLS socket that called `shutdown()` mid-handshake never fired `close` after `end()` while the peer stayed connected. The next socket to do the same never got its `handshake` callback. - Fixed: on a `Bun.listen()` TLS server, `socket.pause()` did not hold for a connection whose handshake was queued because many handshakes arrived at once. `handshake` and `data` still fired on it. ### Runtime - Fixed: on Linux and macOS, after a script accessed a piped `process.stdout` or `process.stderr`, a full pipe made `console.log()` and `console.error()` silently drop the rest of their output, and made writes in `stdio: "inherit"` children fail with `EAGAIN`. - Fixed: on Linux and macOS, an un-awaited `Bun.write(Bun.stdout, new Response(stream))` to a full pipe truncated the output and exited with code 0 when nothing else kept the event loop alive. - Fixed: on Linux and macOS, a read from `process.stdin` or a child process's `stdout` that failed right after returning data (for example `ECONNRESET`) could end the stream with `'end'` instead of `'error'`. - Fixed: a promise that `fetch()`, `Bun.write()`, `server.fetch()` or `Bun.resolve()` returned already rejected (for example `fetch("http://[bad")`) never emitted `unhandledRejection` when nothing awaited or caught it, so the process exited 0. - Fixed: promise callbacks queued from a `beforeExit` listener (for example the code after an `await`) never ran before `exit`. This needed a script that had not yet used `process.nextTick` or loaded `node:stream`. - Fixed: `drainMicrotasks()` from `bun:jsc` also ran queued I/O and `postMessage` callbacks, nesting them inside the calling callback. It now drains only microtasks and `process.nextTick`. - Fixed: in JIT-optimized functions, a `using` dispose method that threw after the block body threw reported its own error instead of a `SuppressedError` carrying both. - Fixed: `error.stack` could show `Error` without the name and message, and drop `new` from constructor frames, if garbage collection ran before the stack was first read. It was reported for errors thrown by an async function and caught after `await`. - Fixed: calling the default `Error.prepareStackTrace` from a custom one (as source-map-support and depd do) headed every stack with `Error` instead of the error's name, like `TypeError`. - Fixed: in non-strict CommonJS code, calling the function that `CallSite.getFunction()` gave a custom `Error.prepareStackTrace` crashed for an async function frame after `await` or a generator frame after `next()`. It now returns `undefined` for internal frames. - Fixed: the first read of `error.stack` crashed when a custom `Error.prepareStackTrace` ran a synchronous GC (`Bun.gc(true)`, a heap snapshot) and the strict-mode function that created the error was already unreachable. Fuzzing found it, and no user reported it. - Fixed: an error message that embedded a string near the maximum string length, as in `Buffer.from("x", "q".repeat(2 ** 31 - 10))`, aborted the process. It now throws a catchable `RangeError`. `.stack` on an error with a message that long now returns `name: message` without the frames. - Fixed: printing an error whose `code` was a `String` object with a throwing `toString` or no prototype crashed with "Bun has run out of memory". - Fixed: a crash when remapping a stack trace if a runtime transpiler cache file had been damaged on disk (by another process or a torn write) and its sourcemap header was invalid. Bun now discards and regenerates the bad entry. - Fixed: `console.log` and `Bun.inspect` ignored the depth limit for nested `Map`, `Set`, `Array` and Error `cause` chains and printed every level. A 1000-deep `Map` printed 2 MB, and nesting thousands of levels deep threw `RangeError`. - Fixed: a rare crash when garbage collection ran while a module that threw during evaluation (e.g. via `import()`) or a failed `Bun.resolve()` was being rejected. - Fixed: `delete require.cache[path]` of an ES module that was still loading, followed by `import()` or `require()` of it, crashed or evaluated the module twice. This needed a CommonJS dependency of that module to delete and re-import it while it loaded. - Fixed: `import()` crashed if `mock.module()`, a plugin's `build.module()`, or a `bun --hot` reload had replaced the module while an earlier `import()` of it was still loading dependencies. - Fixed: a runtime plugin's `onResolve` could run up to three times for one `import` or `require()`, the extra times on its own answer. It now runs once, when that line executes. - Fixed: `require()` of a path that a plugin's `onResolve` put in a namespace failed with `Cannot find package`. It now loads through the plugin's `onLoad`, like `import`. - Fixed: a plugin whose `onResolve` maps `a` to `b` and `b` to `c` loaded `c` for `a`. It now loads `b`. - Fixed: a `require()` in a branch that never ran still called a plugin's `onResolve`. - Fixed: a plugin's `onResolve` that threw failed the whole file. It can now be caught by a `try` around the `require()`. - Fixed: `import()` resolved a relative `path` from a plugin's `onResolve` against the working directory instead of the importing module. - Fixed: each garbage-collected module leaked the string that held its `import.meta` URL. Re-importing after `delete require.cache[...]`, hot reloading, or terminating Workers leaked one such string per module. - Fixed: on Linux, `process.on("memoryPressure")` emitted a false `critical` event shortly after a listener was added, with no real memory pressure. Hosts running a privileged PSI watcher such as `systemd-oomd` did not see it. - Fixed: on Linux without `pidfd_open` (an old kernel, or a seccomp filter that blocks it), a child process exiting could interrupt a system call on the main thread with `EINTR`. A native addon or `bun:ffi` call that doesn't retry could see a failed `read()`. - Fixed: Bun crashed at startup when the working directory, a `--config` path, or `$XDG_CONFIG_HOME`/`$HOME` was so long that adding `bunfig.toml` passed the maximum path length (4096 bytes on Linux, 1024 on macOS). - Fixed: on macOS, `bun --watch` leaked one file descriptor for the project directory on every reload. - Fixed: `bun --watch` and `bun --hot` kept a file descriptor open for every directory the resolver read, reaching thousands in `node_modules`-heavy monorepos. - Fixed: after a reload followed by a garbage collection, `bun --hot` could crash, stop reloading on save, or report an already-handled rejection as the entry point's error. Which one, if any, depended on what the program allocated next. - Fixed: on Linux, a seccomp profile that fails `faccessat2` with `EPERM` or `EINVAL` made a hoisted `bun install` from a warm cache fail with "package was not found in the cache". Regression in Bun v1.4.0. - Fixed: on Linux, a seccomp profile that denies `prlimit64` made `bun install`, `bun build` and `bun run