Sounds interesting. It's a bit unclear for me what the "runs in 15ms" means. I think in my projects, the TypeScript compilation is what takes the longest, so although I use parcel and it's pretty fast, I still have to wait 1-2 seconds for TypeScript to compile changes. If it does not bundle, and still uses all the external transformers (TypeScript, Babel, etc.), what exactly does it do? Does it somehow optimize the execution of those transformers/transpilers?
> I think in my projects, the TypeScript compilation is what takes the longest, so although I use parcel and it's pretty fast, I still have to wait 1-2 seconds for TypeScript to compile changes.
The build result doesn’t need to wait on the results of the type checking. TypeScript or Babel transpiling can happen even if there is a type error.
> If it does not bundle, and still uses all the external transformers (TypeScript, Babel, etc.), what exactly does it do? Does it somehow optimize the execution of those transformers/transpilers?
It skips the bundling step, and does aggressive caching.
> The build result doesn’t need to wait on the results of the type checking. TypeScript or Babel transpiling can happen even if there is a type error.
I do run TypeScript async with Parcel, but I still wait for it to finish before I start working on a different task as I do want to know if I have any TS errors before proceeding.
> It doesn’t optimize the transformers/transpilers; but it does only run them against the modules that have changed.
But isn't this how other bundlers work too? They cache results and only run transformers on the changed files?
I tweaked my comment a little. I’m not sure exactly how webpack is doing it’s work, but I think you’re right.
I think the big optimization is skipping the bundling. If you want to wait on type checking results, and that’s the slowest part, then I don’t see how this could speed up your builds.
