💡 use esbuild via tsup (or swc)

[c43721]

tsup is a very powerful build tool that harvests esbuild to compile typescript very quickly (like, subsecond crazy).

Current Issue tsc is really slow. It's written in TS, which means it doesn't have the power as a go or rust backed build tool. There's even plans to outright rewrite it in Go. Buuut until that happens, nothing we can do as we're growing more and more.

The Solution Replace all tsc with tsup. We'll stay fast forever (so as long as we don't use decorators 😬) with the added benefit of tsup being able to do clean builds, restart on success through --onSuccess, and whatever else esbuild can do in the future.

The Drawbacks This is kinda silly right? Spending 10 minutes installing and configuring esbuild for what? 800ms improvement? I thought this at first as well. But after testing it on my bot (which sadly uses decorators 😬) - which is quite large, it was obvious that tsup improves developer experience not just with the improved build speeds, but the onSuccess helper and auto-clean builds. Those are 2 things that are done manually at the moment, see the package.json to get an idea. This could be replaced by the compiler. Good argument there, then it would work on all operating systems 🥳!!

The Alternatives Like every developer in the world, apparently 200ms build times is still "too slow", so they invented @swc/core (Hey wait a second, this is the same guy who wanted to rewrite tsc in Go...). Wow. swc is written in Rust, and it's super fast. Stupidly fast for us. I compared them on my bot and found a 71 millisecond difference. Wait, that's not a lot.. 🤔.... Right! They're both plenty fast for us. So the argument switches from "Which one is faster?!" to "Which one has the best DX" and that's by far tsup. Though, if we ever touch decorators, @swc/core has support for them and likely will have more support around it in general.

My take I think this is only a benefit. As Needle grows, there's going to be more and more TS to compile. With that, comes the annoying reality of waiting slightly longer each time. Making this switch now will eliminate that worry and provides us with super speedy builds, no matter how large this project grows. Take that with the improved developer experience and I think it's a sell. This is also relatively low cost, as most of the setup for esbuild is hidden away in a neat, type-safe package.

[MarcusOtter]

work on all operating systems

This is the real benefit to me. tsc speeds are negligible at the moment and I don't expect the bot to grow into a large beast any time soon. Especially since they are rewriting it in go, I don't see any performance issues with tsc whatsoever yet, and it will only get better. However, the cross-platform clean builds is something I really want, so I will look into if this is possible with tsc and if not, I will check out tsup!

[c43721]

Agreed. The project to port to Go is going to be months away, and by that time we're likely to see the issues that could appear in large TS codebases.

That cross platform build and auto-restart functionaity is just the icing on the cake for development in TS. I hope that's an option in tsc because it's really annoying when you delete a file, to also delete dist/. This is actually what nestjs does while building- they use rimraf (rm -rf cross-platform package). That's a package to add though, which is what we are trying to avoid 😬.

I'd like to hear what you find. I'll make a draft PR just because it's so much fun seeing you run npm run build and then like 50ms later get a build output of all your compiled js and their d.ts + mapping files. Great feeling sometimes 🙂

I don't see any performance issues with tsc whatsoever yet

What, you don't think 800ms is an improvement 😜. Yeah, keeping this bot minimalistic and small will keep it this way.

[c43721]

I was wrong, it wasn't 50ms, it's 20ms. What an improvement.