Tsdown – The Elegant Bundler for Libraries | Hacker News Reader

Tsdown – The Elegant Bundler for Libraries

tsdown.dev

28 pointsjcbhmr10 comments

We've switched over our libraries at $WORK to use `tsdown` and it's mostly been a very boring journey, we switched from `tsup` and the DX gains have been massive. Running our `dev` process in the frontend monorepo compiles and bundles all the libraries in less than a second on a cold start compared to `tsup` which was far slower. The biggest gain however was in our CI/CD pipeline where the build servers are much weaker than our developer machines, the `build` step in the quality gate for example went down by over a minute. We've also switched to the new native `tsgo` [0] for type checking, saving us another minute on CI/CD and have migrated a few things from ESLint to Oxlint, which was another easy minute saved. And we switched from Prettier to Biome, and checking the formatting on CI went from ~15s to ~1s. Massive gains are being had in the JS-world from gradual oxidation. Can't wait for Vite with rolldown, we tried that but have a few libraries that depend on SWC which made it a show stopper.

[0]: https://github.com/microsoft/typescript-go

The website doesn’t tell me why I would use this instead of just Rolldown.

The “What is tsdown” link goes to a video with pre-roll ads.

I put the video URL into Gemini and asked it what it does. Gemini hallucinated a comparison with Rspack.

I followed the link to documentation from the YouTube description and it took me back to the main page that does not have a description of what it does.

There is an FAQ with a single question:

> Will tsdown support stub mode (similar to unbuild)?

Is there any kind of text description available for what this is and why I – as somebody who is currently writing a lot of front-end code – should care?

Good point! Will improve this.

Think of it as in opinionated Rolldown-"preset" for libraries. It will be used as the foundation of Vite's lib mode revamp.

Afaict, it seems like a rust build on top of oxc and roll down?

But again, all it says is it's fast. And vite is pretty damn fast and widely supported so?

Plus vite exposes roll down config options so yea, what's the point?

I use it to compile backend code. For those use-cases, IMO, vite itself is not so interesting (although I do use vitest). Using tsdown gives me a simplified API to compile my BE code so I can publish it to NPM. Nothing more nothing less. It’s faster and less work to orchestrate using TSC for CJS and ESM output, so very high ROI for me.

I’m using tsdown for a collection of packages and am switching a current project (https://flystorage.dev)over to it. I use it in “unbundle” mode, which doesn’t bundle but does file for file transpilation. To me, it’s an opinionated rolldown configuration with a simplified API. You can script up in a couple of lines of code which packages in a monorepo to compile and what formats to compile for. An example of that can be found here: https://github.com/duna-oss/deltic/blob/main/tsdown.config.t...

Compared to using plain tsc to compile the code, is that it’s a lot quicker. The compiled code has some odd conventions, like using void 0 instead of undefined, but … whatever works!

So far, it has been an easy-entry high-ROI tool that helps me publish TS/JS tools quite easily.

I want to move a project I work in over from tsc to tsdown this week at some point, also with the unbundled mode.

Currently we're using tsc with the new build mode to build everything at once, but the result is incredibly brittle and requires a lot of unnecessary extra configuration all over the place that tends to confuse people when they need to add extra packages or make changes somewhere. It's also very slow (hopefully something that will be fixed by tsgo, eventually).

My initial plan was to have a separate tsdown config in each package and use pnpm to build the entire monorepo (or at least, the parts necessary for each sub-application) in parallel. But your config also looks like a useful approach, I'll explore that as well. Thanks for sharing!

Take a look at workspace mode for that! See e.g. https://github.com/vue-macros/vue-macros/blob/main/tsdown.co... for reference.

What's the point of bundling libraries? Bundling applications, ok, but libraries? Unless they are dynamically imported straight into browser, then it doesn't matter for any use case I can figure.

For node applications, startup time is impacted by IO a many files is less nice for IO wait times. So bundling does make a material impact for non-bundled backend applications and large libraries. I do agree, most impact is had when using bundling at a moment closer to the deployment.

Reply on news.ycombinator.com