- Category
- Developer Tools
- Rank
- No. 06Tools index
- Type
- TOOL
- Builder
- oven-sh
- GitHub
- 96.0k stars
- Latest release
- bun-v1.4.2
- Date
About
An all-in-one JavaScript runtime, bundler, test runner, and package manager built for speed as a drop-in Node.js replacement.
What it does
Bun is a single command-line program that replaces a whole JavaScript toolchain: it runs code, installs dependencies, bundles server and client projects in one step, and executes tests. It also ships a large built-in standard library, including an HTTP server, WebSockets, SQLite, PostgreSQL, Redis and S3 clients, and a shell. Under the hood it is a Rust codebase of a hundred crates that runs JavaScript on the JavaScriptCore engine rather than V8, the engine Node uses, and its bundler can produce single-file executables.
Why it's ranked here
Collapsing a runtime, package manager, bundler and test runner into one binary is the case for it, and the project backs that up with visible discipline: every compiler warning is treated as a build failure across the whole Rust codebase, a canary build ships on every commit, and the documentation covers each subcommand flag by flag. The one thing you cannot settle from the repository alone is licensing: the root manifest is marked private and declares no license at all.
What's good
The codebase enforces its own standards mechanically: every compiler warning, every piece of dead code, and every undocumented unsafe block fails the build, which matters in a project this heavy on low-level system bindings. Comments carry reasoning rather than restating rules, down to why one memory-safety check is disabled because the JavaScript engine's garbage collector cannot tolerate it, and every suppressed memory leak must name an owner. The test runner's documentation covers what large suites actually need: sharding, shards balanced by recorded timing, seeded random ordering, retries and bail-out.
Tradeoffs
Compatibility carries asterisks you must check yourself: the docs call full Node compatibility an ongoing effort, and the Jest-style test API admits not everything is implemented, so migration risk sits in whichever of your dependencies reaches for a missing API. The platform floor is Linux kernel 5.1, and older x64 machines may need baseline builds to avoid illegal-instruction crashes. Contributing is heavy, with more than a dozen build profiles, a separate browser-engine build target, and release links that take minutes. The bundler is also explicitly not a replacement for the TypeScript compiler's typechecking or type declarations.
How to use it well
Adopt it one subcommand at a time rather than as a wholesale runtime swap. The install and test commands are pitched as usable in existing Node projects with little to no change, which makes them the cheap entry point; keep the TypeScript compiler in the loop for typechecking. In CI, pin the version, then add test flags in the documented order: parallel execution first, shared-process mode only if your test files genuinely do not leak state into each other, sharding across machines, and timing data so shards are cut by recorded duration rather than file count. Run randomized ordering once before trusting shared-process mode.
Technical notes+
The entry point is src/bun_bin/lib.rs, an extern C main that the C runtime startup object resolves against; it captures argv before anything else because on musl static builds the standard library hook receives no arguments and std::env::args_os() would come back empty, then installs the crash handler, ignores SIGPIPE and SIGXFSZ, registers mimalloc as the global allocator (swapping to std::alloc::System under ASAN), initialises stdio sinks and the per-thread stack-limit cache, and hands off to the CLI dispatcher. Cargo.toml lists 100 workspace member crates on Rust edition 2024; its release profile sets lto to fat, codegen-units to 1 and panic to abort, and it denies rustc warnings, dead_code and unreachable_pub plus clippy undocumented_unsafe_blocks, mem_forget, uninit_vec and cast_ptr_alignment. src/bun_bin/lib.rs documents why ASAN stack-use-after-return detection is disabled: JavaScriptCore's conservative GC cannot see a heap-backed fake stack. src/bundler/lib.rs implements the bundler as its own crate, a parse-task thread pool feeding a linker graph, with chunk computation, cross-chunk dependencies, parallel chunk generation and symbol renaming each declared as a module. docs/test/index.mdx documents --parallel, --no-isolate, --shard, --timings, --randomize, rerun-each, bail and retry; docs/bundler/index.mdx states the bundler does not replace tsc for typechecking or type declarations. package.json sets private to true and declares no license field.
Observed
- Implementation language
- Rust workspace of 100 member crates
- JavaScript engine
- JavaScriptCore, in contrast to V8, the engine Node.js uses
- Interfaces
- Single CLI binary with subcommands for running code, installing packages, bundling, and testing
- License
- Root package manifest is marked private and declares no license field
- Platform support
- Linux kernel 5.1 minimum (5.6 recommended); baseline builds offered for older x64 CPUs
Read from README.md, package.json, Cargo.toml, docs/index.mdx, docs/runtime/index.mdx, docs/bundler/index.mdx, docs/test/index.mdx, src/bun_bin/lib.rs, src/bun_core/lib.rs, src/bundler/lib.rs.
Intel on Bun
Tags
Tech Stack
Comments (0)
No comments yet
Editorially curated, with community endorsements as a secondary signal. Corrections welcome.