[noahtallen]

It could be, but even today without Bun, a common approach is to do type checking in a separate step from the build. This is because tsc doesn’t parallelize well, so type checking will slow down the build a lot. So you can put the type check step in a separate CI job, and have it fail like unit tests would. Then the main build can be a lot faster since it just has to strip the annotations.

Plus, for local dev, iteration and watch/rebuild is more important than failing with invalid types on every change. Sometimes it’s helpful to circle back to fix/update types after you’ve tried a couple approaches. (TS can still be finicky at times!) On top of that, your IDE should report type errors as you work anyways.

[galaxyLogic]

Makes sense.

I would still prefer though that Bun did it for me, in a separate process perhaps, so I wouldn't need to configure a separate CI job, or manually enter the tsc-command. I read that Bun has its own test-runner too so why not its own type-checker too.

On Node.js I just edit the source-code then re-start the debugger on it, and edit it while in the debugger then rinse and repeat.

I use runtime assertions to catch errors in argument-types etc. as needed.

[nsonha]

the only time you run type-checker is on CI. For the majority of the time you only need the code to compute and your editor/IDE should already have its own bundled type-checker. Unless bun has its own type-checker which means it has to play catch-up with tsc (if that's even possible, typescript's type system is very complex), I don't find a lot of benefit for Bun to merely call tsc for me.