Bun bun-v0.0.40stable Released Oct 29, 2021
Impact Score: 5/10

Bun v0.0.40

Source available โ€” automated, not human-reviewed

Component: bun ยท Channel: stable. Automated analysis, not a compatibility certification. How this works.

Analysis updated: 2026-11-01.

Compatibility not verified โ€” check source notes
๐Ÿ“„ .MD
โšก Executive Summary (TL;DR)

Bun bun-v0.0.40. Source highlight: It's been a busy couple weeks.

Who Does This Impact? (Role-Based Analysis)

๐Ÿ’ป Software Engineers & Devs

Check the source notes against the package and APIs you use before upgrading.

๐Ÿ“Š Product & Engineering Leads

Use the documented changes to assess relevance to your product; release frequency alone is not a quality measure.

โš™๏ธ DevOps & Security

Verify the target version, runtime requirements and rollback procedure in the official documentation.

โœจ New Features & Capabilities (1)

  • `bun run` also adds any `node_modules/.bin` executables to the PATH, so e.g. if you're using Relay, you can do `bun run relay-compiler` and it will run the version of `relay-compiler` for the specific project.

โšก Performance & Enhancements (1)

  • Improved testing coverage. Bun now has integration tests that check a simple Next.js app bundles & server-side prerenders successfully. If JavaScriptCore's JIT is not enabled while server-side rendering, the tests fail. Another integration test checks that a simple Create React App loads. It uses `bun create` to bootstrap the projects.

๐Ÿ”ง Bug Fixes & Patches (2)

  • Fix all known unicode encoding & decoding bugs. Part of what makes parsing & printing JavaScript complicated is that JavaScript officially uses UTF-16 for strings, but the rest of the files on your computer likely use UTF-8. This gets extra complicated with server-side rendering because JavaScriptCore expects either a UTF-16 string for source code or a UTF-8 string. UTF-16 strings use about twice as much memory as UTF-8 strings. Instead of wasting memory, Bun escapes the strings where necessary
  • Fixed several edgecases with the `.env` loader. `.env` values are now parsed as strings instead of something JSON-like
๐Ÿ“„ View Raw Release Notes (Original Developer Log)
It's been a busy couple weeks. Important: the `bun-cli` npm package is deprecated. It will not receive updates. Please upgrade Bun by running: ```bash # Remove the npm version of bun npm uninstall -g bun-cli # Install the new version curl https://bun.sh/install | bash ``` For future upgrades: ```bash bun upgrade ``` Now the fun part. # bun run ~**35x faster package.json** `"scripts"` **runner, powered by Bun**. Instead of `npm run`, try `bun run`. Like `npm run`, `bun run` reads `"scripts"` in your package.json and runs the script in a shell with the same `PATH` changes as npm clients. Unlike npm clients, it's fast. <img width="635" alt="CleanShot 2021-10-28 at 19 29 21@2x" src="https://user-images.githubusercontent.com/709451/139363777-88386b16-89c6-468e-9364-4f003cb3fc38.png"> **You can use `bun run` in projects that aren't using Bun for transpiling or bundling**. It only needs a `package.json` file. When scripts launch a Node.js process, `bun run` still beats `npm run` by 2x: <img width="775" alt="CleanShot 2021-10-28 at 19 37 43@2x" src="https://user-images.githubusercontent.com/709451/139364495-e9c7e7fb-62da-4e2a-8451-ca813e574273.png"> Why? Because npm clients launch an extra instance of Node.js. With `npm run`, you wait for Node.js to boot twice. With `bun run`, you wait once. For maximum performance, if nested `"scripts"` run other npm tasks, `bun run` automatically runs the task with Bun instead. This means adding many tasks won't slow you down as much. `bun run` supports lifecycle hooks you expect like `pre` and `post` and works when the `package.json` file is in a parent directory. Two extra things: - `bun run` also adds any `node_modules/.bin` executables to the PATH, so e.g. if you're using Relay, you can do `bun run relay-compiler` and it will run the version of `relay-compiler` for the specific project. - `bun run` has builtin support for `.env`. It reads: `.env.local`, then `.env.development` || `.env.production` (respecting your `NODE_ENV`), and `.env` in the current directory or enclosing package.json's directory Oh and you can drop the `run`: <img width="290" alt="CleanShot 2021-10-28 at 20 27 30@2x" src="https://user-images.githubusercontent.com/709451/139370838-e54c6a57-be3b-4245-a4fe-d1246bd6e8a4.png"> # Reliability Lots of work went into improving the reliability of Bun over the last couple weeks. Here's what I did: - Rewrote Bun's filesystem router for determinism and to support catch-all + optional-catch-all routes. This is an oversimplification, but the routes are sorted now - Improved testing coverage. Bun now has integration tests that check a simple Next.js app bundles & server-side prerenders successfully. If JavaScriptCore's JIT is not enabled while server-side rendering, the tests fail. Another integration test checks that a simple Create React App loads. It uses `bun create` to bootstrap the projects. - Fix all known unicode encoding & decoding bugs. Part of what makes parsing & printing JavaScript complicated is that JavaScript officially uses UTF-16 for strings, but the rest of the files on your computer likely use UTF-8. This gets extra complicated with server-side rendering because JavaScriptCore expects either a UTF-16 string for source code or a UTF-8 string. UTF-16 strings use about twice as much memory as UTF-8 strings. Instead of wasting memory, Bun escapes the strings where necessary (but only for server-side rendering) - Fixed several edgecases with the `.env` loader. `.env` values are now parsed as strings instead of something JSON-like There's still a lot of work ahead, but Bun is getting better. Sometimes, speed and reliability is a tradeoff. This time, it's not. Bun seems to be about **3% faster overall** compared to the last version (v0.0.36). Why? Mostly due to many small changes to the lexer. Inlining iterators is good.