You can rather easily write rules with GNU make that sit at the comfortable middle ground between these two.
E.g. if you have 1000 JS files to generate from 1000 source TS files you'd "shard" them dynamically by having them batched N at a time, e.g. batches of 10 or 100.
You need to dynamically evaluate Makefile rules into existence for that to work.
I haven't used "tsc", but most compliers with start-up overhead care if you invoke them for every file. But if you can amortize that over N any resulting slowdowns are generally lost in the noise.
Why do that? Because if you have other rules that rely on all that JS being built, it can be much faster overall.
If some of the files are finished you can use free CPU cores for those follow-up rules, as opposed to waiting for "tsc" to build every last one.
It also makes your build system UK much better.
I know some think "good UX" and "GNU make" are diametrically opposed concepts, but being able to ask it "what do I need to incrementally generate to make X" for any file is really useful.
That works much better if your build system doesn't have one big "do all the things" step that's essentially reimplementing most of GNU make.
Comments
You can rather easily write rules with GNU make that sit at the comfortable middle ground between these two.
E.g. if you have 1000 JS files to generate from 1000 source TS files you'd "shard" them dynamically by having them batched N at a time, e.g. batches of 10 or 100.
You need to dynamically evaluate Makefile rules into existence for that to work.
I haven't used "tsc", but most compliers with start-up overhead care if you invoke them for every file. But if you can amortize that over N any resulting slowdowns are generally lost in the noise.
Why do that? Because if you have other rules that rely on all that JS being built, it can be much faster overall.
If some of the files are finished you can use free CPU cores for those follow-up rules, as opposed to waiting for "tsc" to build every last one.
It also makes your build system UK much better.
I know some think "good UX" and "GNU make" are diametrically opposed concepts, but being able to ask it "what do I need to incrementally generate to make X" for any file is really useful.
That works much better if your build system doesn't have one big "do all the things" step that's essentially reimplementing most of GNU make.