Uh oh!
There was an error while loading. Please reload this page.
Syntax only server creates inferred project with all the open files w… - #38561
Conversation
…ith noResolve and can handle semantic operations
Sheetal Nandi (sheetalkamat)
commented
May 13, 2020
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. |
Sheetal Nandi (sheetalkamat)
commented
May 13, 2020
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. |
Sheetal Nandi (sheetalkamat)
commented
May 14, 2020
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) |
Andrew Casey (amcasey)
commented
May 14, 2020
I'll be interested to see what this does to startup perf on the syntax server. Looks pretty cool though. |
Andrew Casey (amcasey)
commented
May 22, 2020
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 |
Cyrus Najmabadi (CyrusNajmabadi)
commented
Jun 11, 2020
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
Sheetal Nandi (sheetalkamat)
commented
Jun 13, 2020
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
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
| } | ||
| } | ||
| 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.
Speaking of logs- do editors log from the syntax server? |
Andrew Casey (amcasey)
commented
Jun 16, 2020
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. |
Sheetal Nandi (sheetalkamat)
commented
Jun 16, 2020
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 #