-
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
Syntax only server creates inferred project with all the open files w… #38561
Conversation
…ith noResolve and can handle semantic operations
@typescript-bot pack this |
Heya @sheetalkamat, I've started to run the tarball bundle task on this PR at 5726838. You can monitor the build here. |
@typescript-bot pack this |
Heya @sheetalkamat, I've started to run the tarball bundle task on this PR at 90d8a96. You can monitor the build here. |
Hey @sheetalkamat, I've packed this into an installable tgz. You can install it for testing by referencing it in your
and then running There is also a playground for this build. |
@mjbvz @minestarks @uniqueiniquity @amcasey @DanielRosenwasser @RyanCavanaugh #38564 is PR that is on top of this and makes normal tsserver behave like syntaxOnly (one with semantic operations allowed) |
I'll be interested to see what this does to startup perf on the syntax server. Looks pretty cool though. |
I've run into a pretty big issue on the VS side: semantic operations tend to be triggered for Roslyn Documents and those don't exist until the project is loaded. So I see operations during project load in already open documents, but not in the newly opened document (i.e. the one that triggered the project load). Obviously, this has nothing to do with the tsserver change. |
@typescript-bot pack this |
Heya @DanielRosenwasser, I've started to run the tarball bundle task on this PR at 90d8a96. You can monitor the build here. |
Hey @DanielRosenwasser, I've packed this into an installable tgz. You can install it for testing by referencing it in your
and then running There is also a playground for this build. |
I'm not able to see things working better with
|
@typescript-bot pack this |
Heya @DanielRosenwasser, I've started to run the tarball bundle task on this PR at 90d8a96. You can monitor the build here. |
Hey @DanielRosenwasser, I've packed this into an installable tgz. You can install it for testing by referencing it in your
and then running There is also a playground for this build. |
I'm finally trying this out with VS Code Insiders! Pretty cool! A couple of thoughts and ideas From the editor side:
From the TypeScript side:
@CyrusNajmabadi, how does Roslyn work when types haven't been resolved yet in things like quick info and signature help? For example we have this signature but |
We don't have that concept :) |
CommandNames.CompileOnSaveEmitFile, | ||
CommandNames.CompilerOptionsDiagnosticsFull, | ||
CommandNames.EncodedSemanticClassificationsFull, | ||
CommandNames.SemanticDiagnosticsSync, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SyntacticDiagnosticsSync: This is somewhat project setting dependent ? Atleast at some point parsing errors use to be different based on target .. eg target determines what unicode is considered identifier start... So i am not sure if this should be enabled.. But if we do enable we i was wondering if GetErr should only do syntax checks and skip semantic and suggetion diagnostics on syntax server
Some questionable which i have disabled for now
Reload
ReloadProjects
PrepareCallHierarchy
ProvideCallHierarchyIncomingCalls
ProvideCallHierarchyOutgoingCalls
@typescript-bot pack this |
Heya @sheetalkamat, I've started to run the tarball bundle task on this PR at 89127a5. You can monitor the build here. |
Hey @sheetalkamat, I've packed this into an installable tgz. You can install it for testing by referencing it in your
and then running There is also a playground for this build. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some comments, but LGTM
@@ -1171,6 +1171,26 @@ namespace ts { | |||
} | |||
} | |||
|
|||
const invalidOperationsOnSyntaxOnly: readonly (keyof LanguageService)[] = [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does this relate to the list in session.ts? Do they need to stay in sync? Is one redundant?
src/services/services.ts
Outdated
if (syntaxOnly) { | ||
invalidOperationsOnSyntaxOnly.forEach(key => | ||
ls[key] = (...args: any[]) => { | ||
throw new Error(`LanguageService Operation: ${key} not allowed on syntaxServer:: arguments::${JSON.stringify(args)}`); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As above, we probably don't need the arguments.
This reverts commit 90d8a96.
Speaking of logs- do editors log from the syntax server? |
VS logging is opt-in (via env var or regkey), but, yes, it applies to both. VS Code only has a command to show the semantic log (AFAIK), but I'm pretty sure it enables both. |
@mjbvz We definitely want users to be able to share the syntaxOnly server logs easily. |
…ith noResolve and can handle semantic operations
Fixes #