I'm using this to compile typescript lambda functions for AWS with great success.
Combined with cdk and its NodeJsFunction you can even deploy/compile without local docker.
Is that correct and how is that working for you practically if it is? The whole point for Typescript for me is to have a compiler typecheck my code and block errors at compile time. ESbuild not typechecking seemed like a major contradiction to using Typescript so I set up a Webpack build using the standard ts compiler.
I've been out the loop of client side stuff a couple of years so to start was bit of a rabbit hole. Grunt/Gulp had gone and now Webpack seems common with a growing fanbase for ESbuild because of it's speed.
This means that for example, during development, you can see your running code quickly, while your editor runs tsc to highlight type checking errors. And in your build system, you can produce a production bundle to test while in parallel checking for type errors.
But:
> Consider TypeScript like a linter
> while in parallel checking for type errors.
Why are you suggesting this not be done during development? Is it bc while ESBuild is fast and runs in parallel, it's still only as fast as the slowest parallelized task, and in this case the slowest task is checking for type errors? And I assume checking for type errors is the slowest because it has to invoke an external resource, tsc?
Would it not make sense to have two development bundlers then? One for getting your code up and running quickly, and a second that outputs a dummy build artifact, but allows a more thorough production-like build that includes type checking (or other long running activities)? That way you get all the verification you would like, but don't pay a price on waiting for your code to deploy?
And yes, type checking is relatively slow, and also strictly extra work, since it's not required to make your code runnable.
You'll often see that people do still do a more thorough production build in their CI systems, but not necessarily by using a bundler that includes type checking; rather, they just run type checking and bundling as separate tasks. That way, you do indeed get all the verification you would like without having to delay deployment.
(To make it somewhat more confusing, a project like Vite does use a fast bundler (ESBuild) during development and a more thorough one for production (Rollup), but that's independent of type checking. It's more about the latter doing more optimisations, and the former merely making the code runnable by the browser.)
If you want, your build script can include
`tsc -noEmit`
Nothing in the above precludes using the compiler to typecheck the code, that's the primary usecase & what sibling is saying about thinking of it as a linter: if typechecking fails, don't build