Bunup builds TypeScript libraries on Bun's bundler, with a scaffold for new ones

What Bunup is for, and who it targets

Bunup helps you ship TypeScript and React libraries faster, with what the documentation calls great developer experience, and it is built on Bun's native bundler. The topic list names build-tool, bun, bundler and typescript, and the badge in the readme says it is built with Bun. That is the whole positioning in one line: this is a library bundler for people who already use Bun, or who are willing to.

The problem it addresses is real but unglamorous. Publishing a TypeScript library means producing a JavaScript build, producing type declarations, wiring the package.json exports field so that consumers can import your subpath, and often shipping CSS alongside the JavaScript. Each of those steps is small, each is easy to get subtly wrong, and together they are the difference between a package that installs cleanly and one that does not. Bunup's stance is that most of this should be the default rather than something you configure.

The audience is library authors, not application developers, and that distinction shows in the feature list. CSS support out of the box with built-in CSS Modules support is aimed at React component libraries. Declaration splitting, described as smaller and cleaner type bundles, matters when your public API surface is narrow but your internals are wide. Auto-exports and unused dependency detection are both about the published package rather than the running app.

The project is MIT licensed, the default branch is main, the homepage is bunup.dev, and the last push to the repository was on 2026-06-17 with the most recent release v0.16.32 on 2026-06-01, after v0.16.31 and v0.16.30 in late February 2026. The version numbering in the 0.16 range, with patch releases, is worth reading as a signal: this is a tool in active iteration rather than a settled one.

The quick start is three commands and one file

The entry path is deliberately short. You write a TypeScript file, in this case a greet function that takes a name and returns a greeting:

// src/index.ts
export function greet(name: string): string {
	return `Hello, ${name}!`;
}

Then you build it:

bunx bunup

The output lands in dist/ with ESM and .d.ts types. There is no config file to write for this case, which is the point of the default. The repository does carry a bunup.config.ts at the root, so configuration is available, but the quick start does not require it.

Two flags cover the most common variations. If you also need CommonJS output, the format flag takes a comma separated list:

bunx bunup --format esm,cjs

And if you want the package exports field generated and synchronised for you:

bunx bunup --exports

That last one deserves a moment's attention because it is the step most hand rolled library builds get wrong. The exports map in package.json is what tells a bundler or Node which file backs which import path, and keeping it in step with the actual output files is exactly the kind of bookkeeping that breaks silently, usually reported by a user as an unhelpful module not found error. Automating it removes the failure mode.

For a monorepo the tool has a workspace mode, described as workspace ready, where you build multiple packages from one config and one command. The documentation links a dedicated workspaces guide, and the examples directory holds a basic-monorepo example alongside the simple library one.

Declaration splitting, which is the feature with the most behind it

Among the listed features, declaration splitting is the one with a linked guide of its own, and the reason is worth understanding rather than just noting. Without splitting, a bundled declaration output ships the types for everything, including internal modules consumers will never touch. The type bundle grows with the codebase rather than with the public API, and in a large library that file becomes a build cost paid by every consumer on every install.

Splitting breaks the declaration output into per-module pieces so that a consumer pulling in one function only pulls in the types for that function's path. The documentation describes the result as smaller, cleaner type bundles, which is the right word because the practical effect is that the published type surface mirrors the module graph rather than being a flat blob.

The rest of the feature list is smaller in scope but still aimed at the same goal. CSS support out of the box means you import CSS directly in your source, and CSS Modules work without extra configuration, which matters for React component libraries where each component ships its own styles. TypeScript declarations are called out separately as clean and accurate.d.ts files. And the batteries included line covers auto-exports and unused dependency detection, the latter being a check that your declared dependencies match what you actually import, which is a common source of install bloat and of runtime failures when a dependency is missing at runtime but present at build time.

The examples directory shows how much of this is aimed at React specifically. There is a React component library styled with plain CSS, one styled with CSS Modules, and one styled with Tailwind CSS, each as a separate example, plus the simple TypeScript library and the monorepo.

Scaffolding a new library, and the monorepo that builds Bunup itself

There is a second package here, and it is arguably more interesting than the bundler for anyone starting from nothing. The scaffold command spins up a modern, ready to publish TypeScript or React component library, or a basic starter, in about ten seconds:

bunx @bunup/cli@latest create

The documentation links a page on scaffolding with Bunup. What matters here is the word ready to publish. The failure mode for a new library author is usually not the bundling, it is the packaging: a package.json that points at the wrong files, an exports map that does not match the output, a missing files field, a types entry that points nowhere. A scaffold that produces a correct package layout removes a class of problems that are tedious to debug later.

The repository is itself a Bun monorepo, and the package.json at the root shows how the project dogfoods its own tooling. The workspaces field covers the docs directory and every package under the packages directory, and the scripts run through bun: a build script that runs the CLI entry point at packages/bunup/src/cli/index.ts, a dev script that runs the same entry point with a watch flag, and separate scripts for the docs build and dev. Linting is oxlint, formatting is oxfmt, and the test scripts run bun test, with a coverage variant and a separate build test for the package's own test directory. Type checking runs filtered across the packages.

The pre-commit hook is the part to note, because it is what makes the tooling credible: simple-git-hooks runs lint and type-check before every commit. The dev dependencies are current and include the TypeScript native preview, oxlint and oxfmt, and types for Bun. This is a project that has been modernised recently, which is consistent with the release cadence and the last push date.

Where Bunup is the wrong choice

The first limitation is the runtime dependency. Bunup is built on Bun's native bundler, which means Bun is part of your build environment whether you like it or not. If your CI is Node.js only, or your organisation has a policy about adding runtimes, that is a real adoption cost, and the tool is not a drop-in for an existing Rollup or esbuild setup. The upside is genuine, since the whole design rests on Bun's speed, but it is a trade rather than a free win.

The second limitation is scope. Bunup is for libraries. The feature list reads like a library publishing checklist, with exports maps, declaration splitting, CSS Modules and unused dependency detection, all of which matter for a package that other people install. It is not positioned as a replacement for an application bundler, and nothing in the documentation suggests it handles things like code splitting for a web app, server rendering, or asset pipelines.

The third limitation is the version. A 0.16 line with patch releases and a last push on 2026-06-17 means the tool is moving, and moving means the configuration options and the CLI flags are still settling. If you adopt it, expect to read the release notes when you upgrade, and pin the version in your own package rather than tracking the latest. The documentation site at bunup.dev is where that documentation lives, and the monorepo examples are the fastest way to see a working configuration for each of the cases you care about.

The realistic alternative is to configure an existing bundler properly. esbuild or Rollup with a small config file, plus a plugin for declaration generation and a script that writes your exports map, gets you the same published output. The difference in approach is defaults versus explicitness: Bunup encodes the library publishing conventions so you do not have to, while the manual route gives you control over every knob at the cost of owning the bookkeeping and the upgrade path. For a team that already has a working build pipeline, Bunup's value is mostly the ergonomics of the defaults, and for a team starting fresh it is a much faster first publish.

Editorial conclusion

Adopt Bunup if you publish TypeScript or React libraries and want a build that is fast by default, with declaration splitting and automatic exports rather than a hand maintained config. Do not adopt it if you are tied to Node.js and npm as the only runtime, since the tool is built on Bun's bundler, and do not expect it to replace every bundler feature, since the documented scope is libraries rather than applications. Before you start, check that Bun is available in your CI, read the workspace guide before configuring a monorepo, and try the scaffold in a scratch directory first, because the generated package layout becomes the layout you maintain.

Frequently asked questions

Official sources

1. bunup/bunup on GitHub
2. License: MIT
3. Project website
4. README
5. Releases