"Initializing JS/TS languages features" never completes after upgrading from 6.4.0 to 6.5.1

[OliverJAsh]

Describe the bug

After opening a TS file, "Initializing JS/TS languages features" never completes after upgrading from 6.4.0 to 6.5.1.

How to reproduce

I tried to reduce this down to a small test case but I didn't have much luck. I decided to file an issue to see if other people are also running into this and also to ask for any debugging tips.

I was able to reproduce it in a fresh instance of VS Code where Abracadabra was the only extension installed.

I tested this in a large repo, however I was not able to reproduce the issue in a much smaller repo.

Expected behavior

"Initializing JS/TS languages features" completes

Screenshots

Additional information

• Version of the extension impacted: v6.5.1

[OliverJAsh]

If I open developer tools in VS Code, I see this in the console:

I suspect this has something to do with the new type-checker module added in #414.

As a side note, it looks like the extension is creating another instance of the TS language service. This is not recommended as it is bad for performance. Instead, the extension should hook into the existing TS language service that VS Code is already running, via a language service plugin.

[nicoespeon]

Thanks for reporting @OliverJAsh 👍

I tested this in a large repo, however I was not able to reproduce the issue in a much smaller repo.

Ah, that's why I wasn't able to repro myself. I will try it out on a large repo to see the impact.

It's very certainly related to the new TypeChecker logic we implemented. It's the major "new" element of the codebase. It probably has to do with the instantiation of a new TS service indeed. The end goal is to tap into the existing one that VS Code uses.

But I thought I could create one on the fly since the scope is limited to a single file: we are using a virtual instance with only the code of the file being processed

abracadabra/src/type-checker/type-checker.ts

Lines 127 to 135 in 795c871

	private createTSProgram(): ts.Program | undefined {
	const host: ts.CompilerHost = {
	...ts.createCompilerHost({}),
	getSourceFile: (fileName, languageVersion) =>
	ts.createSourceFile(fileName, this.code, languageVersion)
	};
	return ts.createProgram([this.fileName], {}, host);
	}

The impact on performance is probably worse than I thought. It may be related to the combination of this and the Action Provider. If so, a quick fix could be to remove the Action Provider until we use VS Code API.

I will try that out on a big repository, run some performance analysis, and find the root cause.

[nicoespeon]

In the meantime, I'm gonna remove the Action Provider. It's a guess but it may solve the problem for you until I sort this out.

You will still be able to run "Destructure Object" through the Command Palette, but it won't appear in the lightbulb suggestions anymore for now.

[rsxdalv]

For those looking for a quick fix, here's a reminder of how to install previous 6.4.0 version:

[OliverJAsh]

Thanks for the quick reply! ❤️

But I thought I could create one on the fly since the scope is limited to a single file: we are using a virtual instance with only the code of the file being processed

Even if you're only checking the types for one file at a time, I imagine TS would still need to resolve the dependency graph of that file in order to compute the type of a given node.

[nicoespeon]

Oh my, what have I done 🤦‍♂️

That is taking an insane amount of time, repeating in a loop.
Alright, disabling the Action Provider for this refactor does fix the performance issue while giving you the option to trigger the refactoring when you need it.

I'm shipping a new patch version with this fix so you can use your editor again. Sorry for the trouble.

I'll fix the perf issue, it's quite obvious what is going wrong here.

[nicoespeon]

@OliverJAsh yeah, the perfs of creating a new TS instance isn't great. It's usable and fine on small files, but takes hundreds of ms (at least) on bigger ones.

The major issue is that I exposed it as a quick fix (Action Provider). VS Code runs that logic every time you move around the file. So expensive calculation + constantly running it = 💣

I didn't catch it before because I was working with relatively small files on a performant machine, so I didn't notice.
Shipping a patch now 🚀

[nicoespeon]

New release created: https://github.com/nicoespeon/abracadabra/releases/tag/6.5.2

It should be available in a couple of minutes 👍

I'll create a specific issue title to track the perf fix of this refactoring, so this one can be retrieved by people who would be stuck in the 6.5.1 situation.

Well, I wanted to dig into accessing VS Code's TS instance anyway. That would unlock multi-files refactorings. I guess now is a good time to dive in 🔦

[nicoespeon]

@OliverJAsh can you let me know if 6.5.2 solves the issue?

[OliverJAsh]

It does, thank you! ❤️

If you do look into language service plugins, I would be very interested to follow along 😄

[nicoespeon]

🙌 Good to hear! Closing the issue then.

I'll definitely look into Language Service plugins. This seems to be the best way to achieve it:

• https://code.visualstudio.com/api/references/contribution-points#contributes.typescriptServerPlugins
• https://github.com/Microsoft/TypeScript/wiki/Writing-a-Language-Service-Plugin

I'll let you know about it 👍