-
-
Notifications
You must be signed in to change notification settings - Fork 26.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TypeScript performance during watch mode #7309
Comments
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 |
I'm curious: if you run standalone tsc -w --notEmit, |
@Bnaya The same happens for Looks like |
Looks like it is a bug in TypeScript itself: microsoft/TypeScript#32294 |
Closing as fix will probably be available in TypeScript v3.7. |
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
intsconfig.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
)The text was updated successfully, but these errors were encountered: