Makes VSCode typecheck veeery slow

[ArthurGoupil]

Hi,

I'm using this wonderful plugin to start the migration of my company huge codebase to typescript strict.
However it makes VSCode typecheck & intellisense very slow, are you aware of this?
If yes, do you have a potential solution in mind?
It looks like the more opened tab I have, the slower it is.

Thanks in advance!
Arthur

[selrond]

Yep, experiencing the same thing. It’s got to the point where we disable the plugin locally and turn on TS strict mode while working, and reenable it before commiting, so the precommit typechecking respect the plugin ignore comments

[trimmurrti]

@selrond @ArthurGoupil Did it ever work fast beforehands at some point in time in vscode?

[selrond]

Don’t think so

[trimmurrti]

@selrond

I'm not a dev for this plugin, but I have a pain similar to yours, which prevents me from adopting this stuff company-wide. Once I wrap up my current commitments, I want to try one thing and possibly have a solution.

Basically, from what I see, the problem is, that we modify global project tsconfig, which ultimately would result in all of the open files being reevaluated. My idea was to create a shadow-project using language service host and basically send all calls to both actual and shadow simultaneously (so that caches are in sync), but return semantic diagnostics from only one of them. The only issue here is, that I would have to use private api, which, as we all know, is the worst idea possible.

The reason I asked, if it was previously working fast was to confirm, if my suspicions were wrong and performance drawback could originate for the repo itself.

Still waiting for response from @ArthurGoupil , tho) PErhaps, he could povide insights I could be missing.

[ArthurGoupil]

Hi @trimmurrti, same as @selrond I don't think it has already been fast

[hnra]

I have been experimenting a bit with your idea @trimmurrti of keeping a separate in-memory version of the project. I have not yet tested it on a large project to see if it actually leads to any performance improvements.

Here's my test plugin project: https://github.com/hnra/strict-plugin-test
Here's essentially the same thing implemented in this repo: https://github.com/hnra/typescript-strict-plugin/tree/in-memory-program

The API usage of createSemanticDiagnosticsBuilderProgram is taken from looking at the source code for createWatchProgram in the TypeScript repo. Not sure if this is the most performant way of incrementally creating a program but it seems to be what the TypeScript watcher does.

[rdrezner]

Got the same issue. I wanted to adopt this plugin in my project, but even though the tsc-strict command works pretty fast and reports issues properly, the VSCode plugin doesn't seem to work at all. I find this piece crucial for the good Developer Experience, and for now its instability causes us to have to give up its adoption.

[selrond]

@rdrezner which TS version is used in your vscode? IIRC, it doesn’t work with typescript >5.2

[rdrezner]

TS version: 5.2.2 (also checked on 5.3.3)
VSCode version: 1.85.2 (Universal)

[rdrezner]

I've just checked with 5.1.6 and it doesn't seem to work either.

The IDE usually does not report any errors. After making some manipulations on the file the IDE sometimes start to report strict mode-related errors but it completely ignores the @ts-strict-ignore comment.

[KostkaBrukowa]

Hey! There is new version that should be faster. You can install and check version 2.2.2-beta.4 and see if it works for you. #67

[rdrezner]

Hey @KostkaBrukowa, I checked version 2.2.2-beta.4, and it works like a charm on both 5.2.2 and 5.3.3 versions of TypeScript. I really appreciate this improvement. I'm looking forward to releasing the production version.

[KostkaBrukowa]

published with 2.3.0 version on npm

[ArthurGoupil]

Unfortunately not much changes with the new version :(

[arn4v]

Found this issue while debugging tsserver slowness in my work project – it appears that this plugin is the root cause. We want to continue using this plugin, so we thought of having a separate tsconfig to use with the tsc-strict command but it seems that tsc-strict doesn't accept custom tsconfig locations. Would be nice to have that as an option so we can have a separate the configs and make our editor experience faster.

[ArthurGoupil]

Found this issue while debugging tsserver slowness in my work project – it appears that this plugin is the root cause. We want to continue using this plugin, so we thought of having a separate tsconfig to use with the tsc-strict command but it seems that tsc-strict doesn't accept custom tsconfig locations. Would be nice to have that as an option so we can have a separate the configs and make our editor experience faster.

Would be a first improvement indeed !

[KostkaBrukowa]

@arn4v have you tried tsc-strict -p ./otherProject/tsconfig.json?

[rikbrown]

I think I also find this plugin breaks Webstorm's error highlighting too. I am seeing with it turned on, on a large project, that Webstorm is failing to syntax highlight things like invalid property access.

I think I'm gonna make a script that only turns it on during build.