Bundlers

Right, so you’ve written a fantastic library in TypeScript. It’s clean, it’s typed, it’s a work of art. Now you need to ship it so that other humans—using different module systems, build tools, and possibly even different versions of Node.js—can actually use it without setting their own hair on fire. This is where Rollup comes in. Think of it less as a “bundler” and more as a “packaging engineer.” Its job is to take your beautifully structured source code and wrap it up in a neat, universally compatible box, complete with a bow (your type declarations).

Alright, let’s get our hands dirty with Webpack. I know, I know, it’s not the cool new kid on the block anymore, but it’s the battle-tested veteran that still powers a massive chunk of the web. And guess what? You’ll probably have to deal with it in a legacy project, or in a team that values its sheer configurability. The good news is, getting it to play nice with TypeScript is straightforward, albeit with a few “why is it like this?” moments.

Right, so you’ve written some TypeScript. Congratulations. Now, how do you get it from a collection of fancy .ts files into something a browser can actually understand without throwing a tantrum? You could wrestle with a complex Webpack config for an afternoon (and I have the grey hairs to prove it), or you could use Vite and have it working in about 30 seconds. Vite is the “just works” tool we’ve been waiting for, and its TypeScript support is so seamless you might forget you’re not just writing JavaScript.

Alright, let’s talk about esbuild. If you’ve ever sat there, watching your terminal churn away, waiting for tsc or Webpack to finish so you can just see if your damn code works, you’re going to love this. Esbuild is a bundler written in Go, and its primary selling point is that it is mind-bendingly fast. We’re not talking “oh, that’s nice” fast. We’re talking “wait, did it even do anything?” fast. It achieves this through a few brutally effective choices: being written in a compiled language, parallelizing everything it can, and avoiding expensive abstractions. It doesn’t do type checking—we’ll get to that—but for pure transpilation and bundling, it’s in a league of its own.

Right, let’s talk about making your code not just correct, but presentable. You’ve got TypeScript telling you your types are wrong, but who tells you your formatting is a mess? You could rely on your own impeccable taste and consistency, but I don’t, and I’m guessing you don’t either. That’s where Prettier comes in. It’s the opinionated code formatter that takes your beautifully functional but visually chaotic code and makes it… well, consistent. It stops all the pointless arguments about semicolons and single quotes in their tracks by simply making the decision for everyone. It’s a dictator, but a benevolent one.

Right, let’s talk about linting TypeScript. You’ve got the TypeScript compiler (tsc) yelling at you about types, which is great, but it’s utterly silent on a million other things that make code good—like code style, potential runtime errors, and patterns that just smell funny. That’s where typescript-eslint comes in. It’s the linter that actually understands your types, and configuring it is the difference between a gentle guide and a chaotic free-for-all.

Right, let’s talk about making your code not just work, but not be an absolute embarrassment to look at. We’ve all been there: you’re three coffees deep, you’ve just hacked together a function that somehow works, and you’d rather delete the repository than have a senior dev look at it. That’s where @typescript-eslint comes in—it’s the brilliant, slightly pedantic friend who reads over your shoulder and says, “You could do that… but you’ll hate yourself in the morning.”