tsdown ships its own source in dev and the built files in production, through one exports map

Two commands, one config file, and a starter you can open in a browser

The documented path from nothing to a build is two commands. The first adds the tool as a development dependency:

npm i -D tsdown

and the second runs it:

npx tsdown

Everything else is preconfigured, which is the stated design: the readme says tsdown sets up what a library needs so you can concentrate on writing code rather than on build configuration. Options live in a tsdown.config.ts file at the repository root, and the full documentation lives on its own site at tsdown.dev rather than in the readme. There is also a StackBlitz starter for the project, linked from the readme badges, so the quickest way to see the defaults applied to a real package is to open it in a browser and change files there.

The exports map serves source in dev and dist files when published

The package manifest carries five entry points, and each one has two forms. The main entry, the config entry, an internal entry, a plugins entry and a run entry are each declared with a dev condition that points into the source tree and a default condition that points at the built file, so a checkout resolves to src and an installed copy resolves to dist. Publishing rewrites all of them: the publishConfig block replaces every dev condition with the dist path and repoints the binary at the built run file. Two further exports are unconditional, the package.json itself and a client declaration file. The files array is short, listing the client declaration, the dist directory and a shim file, so the tarball carries the build and not the tests. That split is what makes the same manifest usable from a monorepo checkout and from the registry.

Three Node ranges are accepted, and pnpm is required to develop

The runtime requirement is declared as an engines range with three accepted forms: a caret range on Node 22 from 22.18.0, a caret range on Node 24 from 24.11.0, and anything from 26.0.0 upwards. The patch floors are the part that bites, since 22.18 and 24.11 are the first releases in those lines that qualify. Development has a separate rule in the devEngines block, which names pnpm as the required package manager at a fixed version and sets the failure action to download, so a contributor without pnpm gets it fetched rather than a build error. The repository agrees with that rule: a pnpm lock file and a pnpm workspace file sit at the root, and a .node-version file records the Node line the project itself develops against.

sideEffects names two paths and claims nothing else

One manifest field is doing quiet work. The sideEffects array contains exactly two entries, the built run file and everything under the tests directory, which tells a bundler that no other file in the package has import side effects. For a tool whose own output is a library, that claim matters: consumers tree shaking their code against tsdown's exports should be able to drop an unused module without changing behaviour. It is also a narrow claim, because the array is an allowlist rather than a description. Anything the package adds later that does have an import side effect has to be added to this list, and the fact that the published files array contains only three entries means there are not many places for such a file to hide.

Rolldown and Oxc do the work, and four plugin ecosystems are accepted

The engine is named rather than implied. Building and generating declaration files are described as powered by Oxc and Rolldown, so the transpile and the type output are not a tsc step bolted onto a bundler. The plugin story is broader than the engine, and it is where most migration friction will live. Support is claimed for Rollup plugins, for Rolldown plugins, for unplugin plugins, and for some Vite plugins. That last qualifier is the one to notice: Vite plugins are admitted as a subset rather than wholesale, so a build that leans on a Vite plugin has to check that specific plugin against the supported list instead of assuming the ecosystem label covers it. The readme presents the migration claim in the same list, describing tsdown as compatible with tsup's main options and features.

Version 0.23.0 with two release candidates three weeks apart

The version line says more about the project than the feature list does. The most recent releases are v0.23.2 on 2026-10-23, v0.23.3 on 2026-10-27 and v0.23.4 on 2026-10-29. The manifest version matches the newest tag, which is not always the case in a fast moving project. The last push to the default branch landed on 2026-11-02, a few days after that tag. A 0.x version also means no stability promise for option names, which is the usual reason to read the tsup compatibility list before moving a production build.

Snapshots, a workspace and agent instructions in the same repository

The repository is set up as a workspace with its own tooling, and the file list shows the pieces. There is a packages directory alongside the root src, a pnpm workspace file, and a scripts directory for the maintenance commands, so the tool and whatever else lives in the monorepo share one lock file. Tests run under Vitest with a snapshot directory committed at the root. Linting uses ESLint with a flat config file and a cache flag, formatting is Prettier with an ignore file, and the site is deployed from netlify.toml. Two directories are aimed at automation rather than users: a skills directory and paired AGENTS.md and CLAUDE.md files at the root, alongside an editorconfig and a taze configuration for the same dependency workflow the project uses on itself.

Editorial conclusion

tsdown fits a library author who wants a smaller build setup than a full bundler, already accepts a Rolldown or unplugin plugin, and is migrating a tsup based build. It does not fit an application bundle, and it is still a 0.x package, so its option names can move. Before adopting it, check that your Node version is inside the declared range, read the tsup compatibility list to see which of your existing options carry over, and confirm the plugins you depend on are in the four supported ecosystems rather than assuming Rollup compatibility extends to them.

Frequently asked questions

Official sources

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