Training Example: Bun – Review the Data, Give Your Score & Compare to the Real AI Evaluation

Bun v1.3.14 is here! →
[H1] Bun is a fast JavaScriptall-in-one toolkit|
Bun is a fast, incrementally adoptable all-in-one JavaScript, TypeScript & JSX toolkit. Use individual tools like bun test or bun install in Node.js projects, or adopt the complete stack with a fast JavaScript runtime, bundler, test runner, and package manager built in. Bun aims for 100% Node.js compatibility.Install Bun v1.3.14Linux & macOSWindowsView install scriptcurl -fsSL https://bun.sh/install | bashpowershell -c "irm bun.sh/install.ps1 | iex"USED BY
[IMG: Lovable logo]
[IMG: CodeRabbit logo]
[IMG: Replit logo]
[IMG: Cursor logo]
BundlerExpressPostgresWebSockets
[H2] Bundling 10,000 React components
Build time in milliseconds (Linux x64, Hetzner)Bunv1.3.0269.1 msRolldownv1.0.0-beta.42494.9 msesbuildv0.25.10571.9 msFarmv1.0.51,608 msRspackv1.5.82,137 msView benchmark →

Bun ships with a fast, built-in, Jest-compatible test runner. Tests are executed with the Bun runtime, and support the following features.
TypeScript and JSX
Lifecycle hooks
Snapshot testing
UI & DOM testing
Watch mode with --watch
Script pre-loading with --preload
Bun aims for compatibility with Jest, but not everything is implemented. To track compatibility, see this tracking
issue.
[H2] ​Run tests
terminalbun test
Tests are written in JavaScript or TypeScript with a Jest-like API. Refer to Writing tests for full documentation.
[IMG: https://mintcdn.com/bun-1dd33a4e/JUhaF6Mf68z_zHyy/icons/typescript.svg?fit=max&auto=format&n=JUhaF6Mf68z_zHyy&q=85&s=7ac549adaea8d5487d8fbd58cc3ea35b]
math.test.tsimport { expect, test } from "bun:test";
test("2 + 2", () => {
expect(2 + 2).toBe(4);
});
The runner recursively searches the working directory for files that match the following patterns:
*.test.{js|jsx|ts|tsx}
*_test.{js|jsx|ts|tsx}
*.spec.{js|jsx|ts|tsx}
*_spec.{js|jsx|ts|tsx}
You can filter the set of test files to run by passing additional positional arguments to bun test. Any test file with a path that matches one of the filters will run. Commonly, these filters will be file or directory names; glob patterns are not yet supported.
terminalbun test <filter> <filter> ...
To filter by test name, use the -t/--test-name-pattern flag.
terminal# run all tests or test suites with "addition" in the name
bun test --test-name-pattern addition
To run a specific file in the test runner, make sure the path starts with ./ or / to distinguish it from a filter name.
terminalbun test ./test/specific-file.test.ts
The test runner runs all tests in a single process. It loads all --preload scripts (see Lifecycle for details), then runs all tests. If a test fails, the test runner will exit with a non-zero exit code.
[H2] ​CI/CD integration
bun test supports a variety of CI/CD integrations.
[H3] ​GitHub Actions
bun test automatically detects if it’s running inside GitHub Actions and will emit GitHub Actions annotations to the console directly.
No configuration is needed, other than installing bun in the workflow and running bun test.
[H4] ​How to install bun in a GitHub Actions workflow
To use bun test in a GitHub Actions workflow, add the following step:
.github/workflows/test.ymljobs:
build:
name: build-app
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Install bun
uses: oven-sh/setup-bun@v2
- name: Install dependencies # (assuming your project has dependencies)
run: bun install # You can use npm/yarn/pnpm instead if you prefer
- name: Run tests
run: bun test
From there, you’ll get GitHub Actions annotations.
[H3] ​JUnit XML reports (GitLab, etc.)
To use bun test with a JUnit XML reporter, you can use the --reporter=junit in combination with --reporter-outfile.
terminalbun test --reporter=junit --reporter-outfile=./bun.xml
This will continue to output to stdout/stderr as usual, and also write a JUnit
XML report to the given path at the very end of the test run.
JUnit XML is a popular format for reporting test results in CI/CD pipelines.
[H2] ​Timeouts
Use the --timeout flag to specify a per-test timeout in milliseconds. If a test times out, it will be marked as failed. The default value is 5000.
terminal# default value is 5000
bun test --timeout 20
[H2] ​Concurrent test execution
By default, Bun runs all tests sequentially within each test file. You can enable concurrent execution to run async tests in parallel, significantly speeding up test suites with independent tests.
[H3] ​--concurrent flag
Use the --concurrent flag to run all tests concurrently within their respective files:
terminalbun test --concurrent
When this flag is enabled, all tests will run in parallel unless explicitly marked with test.serial.
[H3] ​--max-concurrency flag
Control the maximum number of tests running simultaneously with the --max-concurrency flag:
terminal# Limit to 4 concurrent tests
bun test --concurrent --max-concurrency 4
# Default: 20
bun test --concurrent
This helps prevent resource exhaustion when running many concurrent tests. The default value is 20.
[H3] ​test.concurrent
Mark individual tests to run concurrently, even when the --concurrent flag is not used:
[IMG: https://mintcdn.com/bun-1dd33a4e/JUhaF6Mf68z_zHyy/icons/typescript.svg?fit=max&auto=format&n=JUhaF6Mf68z_zHyy&q=85&s=7ac549adaea8d5487d8fbd58cc3ea35b]
math.test.tsimport { test, expect } from "bun:test";
// These tests run in parallel with each other
test.concurrent("concurrent test 1", async () => {
await

[H2] ​Basic Usage
terminalbun install react
bun install react@19.1.1 # specific version
bun install react@latest # specific tag
The bun CLI contains a Node.js-compatible package manager designed to be a dramatically faster replacement for npm, yarn, and pnpm. It’s a standalone tool that will work in pre-existing Node.js projects; if your project has a package.json, bun install can help you speed up your workflow.
⚡️ 25x faster — Switch from npm install to bun install in any Node.js project to make your installations up to 25x faster.
[IMG: Bun installation speed
comparison]
To install all dependencies of a project:
terminalbun install
Running bun install will:
Install all dependencies, devDependencies, and optionalDependencies. Bun will install peerDependencies by default.
Run your project’s {pre|post}install and {pre|post}prepare scripts at the appropriate time. For security reasons Bun does not execute lifecycle scripts of installed dependencies.
Write a bun.lock lockfile to the project root.
[H2] ​Logging
To modify logging verbosity:
terminalbun install --verbose # debug logging
bun install --silent # no logging
[H2] ​Lifecycle scripts
Unlike other npm clients, Bun does not execute arbitrary lifecycle scripts like postinstall for installed dependencies. Executing arbitrary scripts represents a potential security risk.
To tell Bun to allow lifecycle scripts for a particular package, add the package to trustedDependencies in your package.json.
package.json{
"name": "my-app",
"version": "1.0.0",
"trustedDependencies": ["my-trusted-package"]
}
Then re-install the package. Bun will read this field and run lifecycle scripts for my-trusted-package.
Lifecycle scripts will run in parallel during installation. To adjust the maximum number of concurrent scripts, use the --concurrent-scripts flag. The default is two times the reported cpu count or GOMAXPROCS.
terminalbun install --concurrent-scripts 5
Bun automatically optimizes postinstall scripts for popular packages (like esbuild, sharp, etc.) by determining which scripts need to run. To disable these optimizations:
terminalBUN_FEATURE_FLAG_DISABLE_NATIVE_DEPENDENCY_LINKER=1 bun install
BUN_FEATURE_FLAG_DISABLE_IGNORE_SCRIPTS=1 bun install
[H2] ​Workspaces
Bun supports "workspaces" in package.json. For complete documentation refer to Package manager > Workspaces.
package.json{
"name": "my-app",
"version": "1.0.0",
"workspaces": ["packages/*"],
"dependencies": {
"preact": "^10.5.13"
}
}
[H2] ​Installing dependencies for specific packages
In a monorepo, you can install the dependencies for a subset of packages using the --filter flag.
terminal# Install dependencies for all workspaces except `pkg-c`
bun install --filter '!pkg-c'
# Install dependencies for only `pkg-a` in `./packages/pkg-a`
bun install --filter './packages/pkg-a'
For more information on filtering with bun install, refer to Package Manager > Filtering
[H2] ​Overrides and resolutions
Bun supports npm’s "overrides" and Yarn’s "resolutions" in package.json. These are mechanisms for specifying a version range for metadependencies—the dependencies of your dependencies. Refer to Package manager > Overrides and resolutions for complete documentation.
package.json{
"name": "my-app",
"dependencies": {
"foo": "^2.0.0"
},
"overrides": {
"bar": "~4.4.0"
}
}
[H2] ​Global packages
To install a package globally, use the -g/--global flag. Typically this is used for installing command-line tools.
terminalbun install --global cowsay # or `bun install -g cowsay`
cowsay "Bun!"
______
< Bun! >
------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||
[H2] ​Production mode
To install in production mode (i.e. without devDependencies or optionalDependencies):
terminalbun install --production
For reproducible installs, use --frozen-lockfile. This will install the exact versions of each package specified in the lockfile. If your package.json disagrees with bun.lock, Bun will exit with an error. The lockfile will not be updated.
terminalbun install --frozen-lockfile
For more information on Bun’s lockfile bun.lock, refer to Package manager > Lockfile.
[H2] ​Omitting dependencies
To omit dev, peer, or optional dependencies use the --omit flag.
terminal# Exclude "devDependencies" from the installation. This will apply to the
# root package and workspaces if they exist. Transitive dependencies will
# not have "devDependencies".
bun install --omit dev
# Install only dependencies from "dependencies"
bun install --omit=dev --omit=peer --omit=optional
[H2] ​Dry run
To perform a dry run (i.e. don’t actually install anything):
terminalbun install --dry-run
[H2] ​Non-npm dependencies
Bun supports installing dependencies from Git, GitHub, and local or remotely-hosted tarballs. For complete documentation refer to Package manager > Git, GitHub, and tarball dependencies.
package.json{
"dependencies": {
"dayjs": "git+https://github.com/iamkun/dayjs.git",
"lodash": "git+ssh://github.com/lodash/lodash.git#4.17.21",
"moment": "git@github.com:moment/moment.git",
"zod": "github:colinhacks/zod",
"react": "https://registry.npmjs.org/react/-/react-18.2.0.tgz",
"bun-types": "npm:@types/bun"
}
}
[H2] ​Installation strategies
Bun supports two package installation strategies that determine how dependencies are organized in node_modules:
[H3] ​Hoisted installs
The traditional npm/Yarn approach that flattens dependencies into a shared node_modules directory:
terminalbun install --linker hoisted
[H3] ​Isolated installs
A pnpm-like approach that creates strict dependency isolation to prevent phantom dependencies:
terminalbun install --linker isolated
Isolated installs create a central package store in node_modules/.bun/ with symlinks in the top-level node_modules. This ensures packages can only access their declared dependencies.
[H3] ​Default strategy
The default linker strategy depends on whether you’re starting fresh or have an existing project:
New workspaces/monorepos: isolated (prevents phantom dependencies)
New single-package projects: hoisted (traditional npm behavior)
Existing projects (made pre-v1.3.2): hoisted (preserves backward compatibility)
The default is controlled by a configVersion field in your lockfile. For a detailed explanation, see Package manager > Isolated installs.
[H2] ​Minimum release age
To protect against supply chain attacks where malicious packages are quickly published, you can configure a minimum age requirement for npm packages. Package versions published more recently than the specified threshold (in seconds) will be filtered out during installation.
terminal# Only install package versions published at least 3 days ago
bun add @types/bun --minimum-release-age 259200 # seconds
You can also configure this in bunfig.toml:
bunfig.toml[install]
# Only install package versions published at least 3 days ago
minimumReleaseAge = 259200 # seconds
# Exclude trusted packages from the age gate
minimumReleaseAgeExcludes = ["@types/node", "typescript"]
When the minimum age filter is active:
Only affects new package resolution - existing packages in bun.lock remain unchanged
All dependencies (direct and transitive) are filtered to meet the age requirement when being resolved
When versions are blocked by the age gate, a stability check detects rapid bugfix patterns
If multiple versions were published close together just outside your age gate, it extends the filter to skip those potentially unstable versions and selects an older, more mature version
Searches up to 7 days after the age gate, however if still finding rapid releases it ignores stability check
Exact version requests (like package@1.1.1) still respect the age gate but bypass the stability check
Versions without a time field are treated as passing the age check (npm registry should always provide timestamps)
For more advanced security scanning, including integration with services & custom filtering, see Package manager > Security Scanner API.
[H2] ​Configuration
[H3] ​Configuring bun install with bunfig.toml
bunfig.toml is searched for in the following paths on bun install, bun remove, and bun add:
$XDG_CONFIG_HOME/.bunfig.toml or $HOME/.bunfig.toml
./bunfig.toml
If both are found, the results are merged together.
Configuring with bunfig.toml is optional. Bun tries to be zero configuration in general, but that’s not always possible. The default behavior of bun install can be configured in bunfig.toml. The default values are shown below.
bunfig.toml[install]
# whether to install optionalDependencies
optional = true
# whether to install devDependencies
dev = true
# whether to install peerDependencies
peer = true
# equivalent to `--production` flag
production = false
# equivalent to `--save-text-lockfile` flag
saveTextLockfile = false
# equivalent to `--frozen-lockfile` flag
frozenLockfile = false
# equivalent to `--dry-run` flag
dryRun = false
# equivalent to `--concurrent-scripts` flag
concurrentScripts = 16 # (cpu count or GOMAXPROCS) x2
# installation strategy: "hoisted" or "isolated"
# default depends on lockfile configVersion and workspaces:
# - configVersion = 1: "isolated" if using workspaces, otherwise "hoisted"
# - configVersion = 0: "hoisted"
linker = "hoisted"
# minimum age config
minimumReleaseAge = 259200 # seconds
minimumReleaseAgeExcludes = ["@types/node", "typescript"]
[H3] ​Configuring with environment variables
Environment variables have a higher priority than bunfig.toml.
NameDescriptionBUN_CONFIG_REGISTRYSet an npm registry (default: https://registry.npmjs.org)BUN_CONFIG_TOKENSet an auth token (currently does nothing)BUN_CONFIG_YARN_LOCKFILESave a Yarn v1-style yarn.lockBUN_CONFIG_LINK_NATIVE_BINSPoint bin in package.json to a platform-specific dependencyBUN_CONFIG_SKIP_SAVE_LOCKFILEDon’t save a lockfileBUN_CONFIG_SKIP_LOAD_LOCKFILEDon’t load a lockfileBUN_CONFIG_SKIP_INSTALL_PACKAGESDon’t install any packages
Bun always tries to use the fastest available installation method for the target platform. On macOS, that’s clonefile and on Linux, that’s hardlink. You can change which installation method is used with the --backend flag. When unavailable or on error, clonefile and hardlink fallsback to a platform-specific implementation of copying files.
Bun stores installed packages from npm in ~/.bun/install/cache/${name}@${version}. Note that if the semver version has a build or a pre tag, it is replaced with a hash of that value instead. This is to reduce the chances of errors from long file paths, but unfortunately complicates figuring out where a package was installed on disk.
When the node_modules folder exists, before installing, Bun checks if the "name" and "version" in package/package.json in the expected node_modules folder matches the expected name and version. This is how it determines whether it should install. It uses a custom JSON parser which stops parsing as soon as it finds "name" and "version".
When a bun.lock doesn’t exist or package.json has changed dependencies, tarballs are downloaded & extracted eagerly while resolving.
When a bun.lock exists and package.json hasn’t changed, Bun downloads missing dependencies lazily. If the package with a matching name & version already exists in the expected location within node_modules, Bun won’t attempt to download the tarball.
[H2] ​CI/CD
Use the official oven-sh/setup-bun action to install bun in a GitHub Actions pipeline:
.github/workflows/release.ymlname: bun-types
jobs:
build:
name: build-app
runs-on: ubuntu-latest
steps:
- name: Checkout repo
uses: actions/checkout@v4
- name: Install bun
uses: oven-sh/setup-bun@v2
- name: Install dependencies
run: bun install
- name: Build app
run: bun run build
For CI/CD environments that want to enforce reproducible builds, use bun ci to fail the build if the package.json is out of sync with the lockfile:
terminalbun ci
This is equivalent to bun install --frozen-lockfile. It installs exact versions from bun.lock and fails if package.json doesn’t match the lockfile. To use bun ci or bun install --frozen-lockfile, you must commit bun.lock to version control.
And instead of running bun install, run bun ci.
.github/workflows/release.ymlname: bun-types
jobs:
build:
name: build-app
runs-on: ubuntu-latest
steps:
- name: Checkout repo
uses: actions/checkout@v4
- name: Install bun
uses: oven-sh/setup-bun@v2
- name: Install dependencies
run: bun ci
- name: Build app
run: bun run build
[H2] ​Platform-specific dependencies?
bun stores normalized cpu and os values from npm in the lockfile, along with the resolved packages. It skips downloading, extracting, and installing packages disabled for the current target at runtime. This means the lockfile won’t change between platforms/architectures even if the packages ultimately installed do change.
[H3] ​--cpu and --os flags
You can override the target platform for package selection:
bun install --cpu=x64 --os=linux
This installs packages for the specified platform instead of the current system. Useful for cross-platform builds or when preparing deployments for different environments.
Accepted values for --cpu: arm64, x64, ia32, ppc64, s390x
Accepted values for --os: linux, darwin, win32, freebsd, openbsd, sunos, aix
[H2] ​Peer dependencies?
Peer dependencies are handled similarly to yarn. bun install will automatically install peer dependencies. If the dependency is marked optional in peerDependenciesMeta, an existing dependency will be chosen if possible.
[H2] ​Lockfile
bun.lock is Bun’s lockfile format. See our blogpost about the text lockfile.
Prior to Bun 1.2, the lockfile was binary and called bun.lockb. Old lockfiles can be upgraded to the new format by running bun install --save-text-lockfile --frozen-lockfile --lockfile-only, and then deleting bun.lockb.
[H2] ​Cache
To delete the cache:
bun pm cache rm
# or
rm -rf ~/.bun/install/cache
[H2] ​Platform-specific backends
bun install uses different system calls to install dependencies depending on the platform. This is a performance optimization. You can force a specific backend with the --backend flag.
hardlink is the default backend on Linux. Benchmarking showed it to be the fastest on Linux.
rm -rf node_modules
bun install --backend hardlink
clonefile is the default backend on macOS. Benchmarking showed it to be the fastest on macOS. It is only available on macOS.
rm -rf node_modules
bun install --backend clonefile
clonefile_each_dir is similar to clonefile, except it clones each file individually per directory. It is only available on macOS and tends to perform slower than clonefile. Unlike clonefile, this does not recursively clone subdirectories in one system call.
rm -rf node_modules
bun install --backend clonefile_each_dir
copyfile is the fallback used when any of the above fail, and is the slowest. on macOS, it uses fcopyfile() and on linux it uses copy_file_range().
rm -rf node_modules
bun install --backend copyfile
symlink is typically only used for file: dependencies (and eventually

Bun’s fast native bundler can be used via the bun build CLI command or the Bun.build() JavaScript API.
[H3] ​At a Glance
JS API: await Bun.build({ entrypoints, outdir })
CLI: bun build <entry> --outdir ./out
Watch: --watch for incremental rebuilds
Targets: --target browser|bun|node
Formats: --format esm|cjs|iife (experimental for cjs/iife)
JavaScript CLI
[IMG: https://mintcdn.com/bun-1dd33a4e/JUhaF6Mf68z_zHyy/icons/typescript.svg?fit=max&auto=format&n=JUhaF6Mf68z_zHyy&q=85&s=7ac549adaea8d5487d8fbd58cc3ea35b]
build.tsawait Bun.build({
entrypoints: ['./index.tsx'],
outdir: './build',
});
terminalbun build ./index.tsx --outdir ./build
It’s fast. The numbers below represent performance on esbuild’s three.js benchmark.
[H2] ​Why bundle?
The bundler is a key piece of infrastructure in the JavaScript ecosystem. As a brief overview of why bundling is so important:
Reducing HTTP requests. A single package in node_modules may consist of hundreds of files, and large applications may have dozens of such dependencies. Loading each of these files with a separate HTTP request becomes untenable very quickly, so bundlers are used to convert our application source code into a smaller number of self-contained “bundles” that can be loaded with a single request.
Code transforms. Modern apps are commonly built with languages or tools like TypeScript, JSX, and CSS modules, all of which must be converted into plain JavaScript and CSS before they can be consumed by a browser. The bundler is the natural place to configure these transformations.
Framework features. Frameworks rely on bundler plugins & code transformations to implement common patterns like file-system routing, client-server code co-location (think getServerSideProps or Remix loaders), and server components.
Full-stack Applications. Bun’s bundler can handle both server and client code in a single command, enabling optimized production builds and single-file executables. With build-time HTML imports, you can bundle your entire application — frontend assets and backend server — into a single deployable unit.
Let’s jump into the bundler API.
The Bun bundler is not intended to replace tsc for typechecking or generating type declarations.
[H2] ​Basic example
Let’s build our first bundle. You have the following two files, which implement a client-side rendered React app.
[IMG: https://mintcdn.com/bun-1dd33a4e/JUhaF6Mf68z_zHyy/icons/typescript.svg?fit=max&auto=format&n=JUhaF6Mf68z_zHyy&q=85&s=7ac549adaea8d5487d8fbd58cc3ea35b]
index.tsx
[IMG: https://mintcdn.com/bun-1dd33a4e/JUhaF6Mf68z_zHyy/icons/typescript.svg?fit=max&auto=format&n=JUhaF6Mf68z_zHyy&q=85&s=7ac549adaea8d5487d8fbd58cc3ea35b]
Component.tsximport * as ReactDOM from "react-dom/client";
import { Component } from "./Component";
const root = ReactDOM.createRoot(