Repository navigation
TypeScript performance during watch mode #7309
Description
CRA performance can still be a pain with TypeScript.
We already reduce the waiting times for type-check by #5903, then we speed it up even more by using the IncrementalAPI in fork-ts-checker-webpack-plugin.
Unfortunately, even after all of these improvements, type-check can took 5 or more seconds to finish in big projects. Yes, it's much better now as you can see your changes immediately and type-errors will appear when they are ready.
Now, the important thing:
I discover that using the isolatedModules: false in tsconfig.json reduces type-checks between code changes from 5 seconds to less than 1 second.
I know the reason, why we are using isolatedModules - it is a limitation of Babel compiler. However, we should definitely do something with it as developers are required to wait a lot of time just to catch a few edge cases.
I'm not sure how to solve it right now but I'm pretty sure that we can figure it out together.
cc @johnnyreilly (creator of fork-ts-checker-webpack-plugin)
Activity
johnnyreilly commentedon Jul 2, 2019
Credit where it's due: @piotr-oles is the creator of fork-ts-checker-webpack-plugin - I've just worked on it an awful lot. And I'm louder 😁
In ts-loader we did fiddling with
isolatedModules. I've actually forgotten most of the details. However here's some links that should provide some useful info:microsoft/TypeScript#16351
TypeStrong/ts-loader#569
Bnaya commentedon Jul 3, 2019
I'm curious: if you run standalone tsc -w --notEmit,
How much time does the typecheck takes? (with and without isolatedModules )
deftomat commentedon Jul 4, 2019
@Bnaya The same happens for
tsc -w --noEmit. So, its definitely the behaviour of TypeScript itself.Looks like
isolatedModuleshas some serious performance implications.deftomat commentedon Jul 10, 2019
Looks like it is a bug in TypeScript itself: microsoft/TypeScript#32294
deftomat commentedon Sep 17, 2019
Closing as fix will probably be available in TypeScript v3.7.