rollup.js has caching mechanism and TypeScript has caching and incremental build features. In spite of using these features the build time was still not fast enough. While some of these techniques helped, there was still a lot of difference in build time. Coming from using golang on a large project prior to this, the build time latency and the resulting productivity loss was very obvious and something had to be done.
After careful consideration, the entire codebase had been once again completely restructured to make use of yarn workspaces and create explicit packages. Incidentally TypeScript compiler even supports this concept and it is possible to build across these isolated packages using
--build flag. With this, the build times have improved as only the changed packages and packages that depend on them are compiled and not the overall codebase. While this solved the compilation and bundling timings the build times for targets requiring transpilation still suffered.
Then I chanced upon esbuild and after reading the project and trying it, I must say, it is a fantastic project. The bundling and transpiling times have gone down to sub-second! So, while incremental compilation time could occasionally spike up to a few seconds, most of the time the entire compilation to transpiling and bundling is all done within a second.
There is one problem with esbuild that may or may not be tolerable for your use case. It has a single pass design which avoids certain types of optimizations (for example, private fields may be converted to WeakMap based fields in some scenarios). Hence, if performance is critical to the application, then it may be better to adopt a dual strategy where the dev builds are based on esbuild and the production builds based on rollup.
I suggest you give it a try. Even if you have a complex build process, figure out a way to isolate parts that can be done with esbuild to shave off several seconds of the build time during development to boost dev productivity.