Skip to content
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

feat: start separate tsServer instance for semantic requests #688

Merged
merged 2 commits into from
Feb 19, 2023

Conversation

rchl
Copy link
Member

@rchl rchl commented Feb 15, 2023

Ported code from VSCode that enables two tsserver instances, one for "syntax" requests and one for "semantic" requests. This should ensure that the more expensive requests like semantic tokens or diagnostic computations don't block more acute requests like completions.

The default is to run with syntax and semantic servers enabled.

Resolves #650 (?)
Resolves #675 (?)

@rchl rchl changed the title feat: start separate semantic tsServer instance for semantic requests feat: start separate tsServer instance for semantic requests Feb 15, 2023
*
* @default 'auto'
*/
useSyntaxServer?: 'auto' | 'never';
Copy link
Member Author

@rchl rchl Feb 15, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like it should be a boolean value but it's this way because VSCode also supports always and I want to have this future-proof in case support for always is added later.

To support always we'd need to add a bunch of checks to avoid triggering certain requests when it's used. Also, I believe that in VSCode the always value is forced by the editor when opening single files and is not really meant to be used manually. So it might require some client glue to be usable in other editors.

@rchl rchl merged commit fa65b84 into master Feb 19, 2023
@rchl rchl deleted the feat/semantic-tsserver branch February 19, 2023 20:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Recognize new import takes too long in large repos [Request for info] open performance work
1 participant