Bun v0.0.40

[Jarred-Sumner]

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:

curl bun.sh/install | bash

For future upgrades:

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.

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:

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:

It's cleaner.

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.

---

This discussion was created from the release Bun v0.0.40.

[KishanBagaria]

i'd change curl bun.sh/install | bash to use https. it's easy for someone to mitm and inject something.

my isp randomly intercepts http traffic - would have gotten compromised in another scenario:

edit: hsts would also be good