Vite rolldown lib mode and tsdown

[jnavb]

I'm currently migrating an existing old monorepo that has some apps and internal library packages containing thousands of files that were previously published as source (unbundled).

The journey so far:

Unbundled source → tsgo (types) + Vite 8 lib with preserveModules — this gave me faster build times.
preserveModules → entryPoints via fs.readdirSync — this was slower due to I/O overhead.
fs.readdirSync → globSync — as recommended in the Rolldown docs, using globSync to create the entry points brought performance back to where it was.

Now I'm tempted to move the library bundling to tsdown and only keep Vite for the actual app builds. As I understand it, tsdown is a nice opinionated wrapper around Rolldown, so my question is: am I leaving anything on the table by staying with Vite lib mode + Rolldown using the glob configuration described above?

I've read this discussion thread as well, but it is a bit dated and, given Vite+'s recent announcement, maybe an update would be nice.

[sxzz]

Common, widely used features won’t be removed, but could you share a few specific examples?

[jnavb]

I'm not sure if my question was interpret the other way around, to clarify: what am I leaving on the table by not using tsdown? We have React component libraries in a monorepo currently built with Vite lib mode, and after reviewing the tsdown docs, the feature set covers everything we need (externalization via deps, SCSS preprocessing, IIFE format for some old internal consumers and asset copying).

The one friction point I see is Vitest co-location, our test config currently lives inside vite.config.mts, so moving lib builds to tsdown means maintaining a separate vitest.config.ts per package. Minor though.

Given that Vite lib mode and tsdown both sit on top of Rolldown now, what are the concrete advantages of using tsdown over Vite lib mode for library bundling? Faster builds? Better DTS generation? Simpler config? I'm fairly convinced the tsdown approach is the right direction, but it'd be great to hear from a maintainer what the strongest differentiators are.

[sxzz]

See https://tsdown.dev/guide/#key-differences-between-tsdown-and-rolldown. These comparisons still apply to Vite.

Also, tsdown provides many built-in features: dts, publint, attw, executables, auto-generated exports, and more. If you read the documentation carefully, you will find the answer.

[jnavb]

The provided link discusses the distinctions between tsdown and Rolldown. The only mention of Vite refers to their now-archived Vite 8 preview: Furthermore, tsdown is positioned to become the foundation for [Rolldown Vite](https://github.com/vitejs/rolldown-vite)'s Library Mode.

• publint / attw: these are already established packages. Having them will indeed improve DX, but it won’t affect people already using them, which is my case.
• executable: n/a for React component libraries or most browser libraries.
• auto-generated export: I can see the benefit here, especially for large monorepos transitioning from source to built packages. Although tsdown is still on v0, I’ve been wary of using this feature because it is marked as experimental in the docs.
• dts: a major benefit here. Avoiding tools like @microsoft/api-extractor / dts-bundle-generator and relying entirely on VoidZero tooling for the build toolchain was my main reason for looking into tsdown.

I hope this serves as a helpful recap of my findings for anyone exploring this topic, though I may be mistaken in parts (@sxzz feel free to point it out). Of course, tsdown offers more features, but this assumes we part from a setup where sourcemaps, declaration maps, CSS bundling, and watch mode are already covered.

Update: Missed to point it out from your response These comparisons still apply to Vite. Knowing that for that particular docs section clears a bit my initial confusion, thanks.