-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Performance with isolatedModules=true #32294
Comments
I'm thinking this probably happens because |
@fatcerberus That's make sense, but I'm wondering if TypeScript is able to use some kind of cache as its probably know, which files changed. The performance difference between these two modes is huge. |
Maybe |
Well, as I know, |
Is there a repo that demonstrates this behavior we could use for testing? |
@RyanCavanaugh https://github.com/microsoft/TypeScript/blob/master/src/compiler/builder.ts#L163 (added by #29252) we do not cache semantic diagnostics with isolated modules. isolatedModules and d.ts emit is disabled right now and is tracked by #29490. Once that's enabled we would be able to change that logic here instead. |
I can confirm this happening on my repo on TypeScript 3.5.3. I turned on isolated modules yesterday when Next v9 was released and its instructions told us to, then the typechecking performance degraded significantly on incremental compilation. Isolated modules
Isolated modules
There's no effect on the first compilation but there's a big difference on the second compilation (when incremental is I can try to pick out some files from my repo for testing if necessary - @sheetalkamat let me know if you need it. |
FWIW, I build all my projects with Babel and type check all of them without |
Is this a bug? |
In case it helps, this can be easily reproduced with just a single file:
(Ignore the first and third invocation of |
Until this gets fixed, can someone update the docs at https://www.typescriptlang.org/docs/handbook/compiler-options.html to indicate that |
TypeScript Version: 3.6.0-dev.20190704 | 3.5.2
Search Terms: isolatedModules, performance
We discovered that using
isolatedModules=false
in React apps drastically decrease type-check times. For example, in our application,tsc --watch --noEmit
can took 5 seconds withisolatedModules=true
. However, when we change it toisolatedModules=false
, then the incremental type-check took 1 second or less.The obvious solution is to disable isolated modules. Unfortunately, our application us
create-react-app
which use Babel to compile TS into JS andfork-ts-checker-webpack-plugin
to run type-checks.Due to Babel limitations,
isolatedModules=true
is a recommended option. TypeScript is definitely fast enough to make developers happy but we are forced to wait a lot of seconds just to catch a few edge cases.So, my question is: Is this a bug or just a limitation of
isolatedModules
option?Being able to use TypeScript in existing Babel toolchains is a huge thing but we are missing the last thing: SPEED 😞
(Related to facebook/create-react-app#7309)
The text was updated successfully, but these errors were encountered: