Skip to main content
Bun’s bundler API is heavily inspired by esbuild. This page is a side-by-side comparison of the two APIs. A few behaviors differ:
Bundling by default. Unlike esbuild, Bun bundles by default; no --bundle flag is needed. To transpile each file individually, use Bun.Transpiler.
Bundler only. Unlike esbuild, Bun’s bundler has no built-in development server. Use it with Bun.serve and other runtime APIs to get the same effect. esbuild’s HTTP options don’t apply.

Performance

Bun’s bundler is 1.75x faster than esbuild on esbuild’s three.js benchmark.
Bundling 10 copies of three.js from scratch, with sourcemaps and minification

CLI API

terminal
In Bun’s CLI, boolean flags like --minify take no argument. Flags that take one, like --outdir <path>, can be written as --outdir out or --outdir=out. Some flags, like --define, can be repeated: --define foo=bar --define bar=baz.

JavaScript API

Plugin API

Bun’s plugin API is designed to be esbuild-compatible. Bun doesn’t support esbuild’s entire plugin API surface, but the core functionality is implemented, and many third-party esbuild plugins work with Bun without modification.
Long term, we aim for feature parity with esbuild’s API. If something doesn’t work, file an issue to help us prioritize.
Plugins in Bun and esbuild are defined with a builder object.
myPlugin.ts
The builder object’s methods hook into parts of the bundling process. Bun implements onStart, onEnd, onResolve, and onLoad; it does not implement the esbuild hooks onDispose and resolve. initialOptions is partially implemented: it’s read-only and exposes only a subset of esbuild’s options. Use config (the same thing in Bun’s BuildConfig format) instead.
myPlugin.ts

onResolve

  • 🟢 filter
  • 🟢 namespace

onLoad

  • 🟢 filter
  • 🟢 namespace