Syntax only server creates inferred project with all the open files w… - #38561
Conversation
…ith noResolve and can handle semantic operations
|
TypeScript Bot (@typescript-bot) pack this |
|
Heya Sheetal Nandi (@sheetalkamat), I've started to run the tarball bundle task on this PR at 5726838. You can monitor the build here. |
|
TypeScript Bot (@typescript-bot) pack this |
|
Heya Sheetal Nandi (@sheetalkamat), I've started to run the tarball bundle task on this PR at 90d8a96. You can monitor the build here. |
|
Hey Sheetal Nandi (@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. |
|
Matt Bierner (@mjbvz) Mine Starks (@minestarks) Ben Lichtman (@uniqueiniquity) Andrew Casey (@amcasey) Daniel Rosenwasser (@DanielRosenwasser) Ryan Cavanaugh (@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 (@typescript-bot) pack this |
|
Heya Daniel Rosenwasser (@DanielRosenwasser), I've started to run the tarball bundle task on this PR at 90d8a96. You can monitor the build here. |
|
Hey Daniel Rosenwasser (@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 (@typescript-bot) pack this |
|
Heya Daniel Rosenwasser (@DanielRosenwasser), I've started to run the tarball bundle task on this PR at 90d8a96. You can monitor the build here. |
|
Hey Daniel Rosenwasser (@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:
Cyrus Najmabadi (@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.
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 (@typescript-bot) pack this |
|
Heya Sheetal Nandi (@sheetalkamat), I've started to run the tarball bundle task on this PR at 89127a5. You can monitor the build here. |
|
Hey Sheetal Nandi (@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. |
Andrew Casey (amcasey)
left a comment
There was a problem hiding this comment.
Some comments, but LGTM
| } | ||
| } | ||
|
|
||
| const invalidOperationsOnSyntaxOnly: readonly (keyof LanguageService)[] = [ |
There was a problem hiding this comment.
How does this relate to the list in session.ts? Do they need to stay in sync? Is one redundant?
| 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.
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. |
|
Matt Bierner (@mjbvz) We definitely want users to be able to share the syntaxOnly server logs easily. |


…ith noResolve and can handle semantic operations
Fixes #