**Problem**
In the ts server communication, canceling a request currently throws an exception. This is wrong because cancellation is not an error. It also means that we need to wrap every server call in a generic try catch to handle cancellation. There are no checks in place to distinquish a cancellation from a rea
**Problem**
We'd like to understand the types of problems users are running into when using the checkJs feature in real world code. This is not something we can determine automatically
**Fix**
The TS team has put together a short survey that will hopefully help them understand how people are using checkJS and what problems they run into. This change adds client side logic to show the survey in the following case:
- A user as opened 10 projects that have checkJS set
- And they have not been prompted to complete the survey previously
- And they have not opted out of all js/ts surveys
`telemetry` is not fired for implicit projects, while `projectsUpdatedInBackground` should always be fired. Gating this to 3.0 since I believe the event was only added recently
Fixes#58560
If the queued (but not sent) ts server request is canceled, we could previously fail to resolve its callbacks. This change makes sure we always resolve the callbacks for cancelled requests
Rebase of a number of incremental changes listed below
Move first level dispatchMessage into ForkedTsServerProcess
Goal is to move callbacks and other per-server state into `ForkedTsServerProcess`
Create forked ts server object syncrounously
There is no reason for this to be async anymore. Making this object sync reduces complexity and makes the code easier to reason about
Moving server relate functions into ForkedTSServer object
The goal here is to have a single "server" object that keeps track of all its relevant state. The service client would manage one of these servers at a time, starting new ones if needed and dispatching to old ones
Split server into own file
Use switch case instead of conditionals
Make pendingResponses readonly
Add typings for callback item
Improve naming
- Use more descriptive names
- Preview private vars with _
Use passed in version for getting command line args
Attach webview click handler to window instead of to document body
Fixes#48926
Change error handling for ts server exit and error
- Don't fire twice on error (once for the `once` and once for the `onError`)
- Flush callbacks on both exit and error.
Remove cancellationPipeName as state
Remove obsolete comment
Move all env generation into generatePatchedEnv
Extract server spawn into static method
Move spawn from static to be own factory class
Move providers from arguments to state on the spawner
Update js/ts grammar
Remove duplicate error handler
Cleaning up server fork
- Standarize names
- Extract methods
- Move some function to be private statics
- Move logging out of electron and into server.ts
Use undefined instead of null for optional value
Splits the old setting into `javascript.suggest.insertParametersForFunctionCalls` and `typescriptscript.suggest.insertParametersForFunctionCalls`
Fixes#58385
* Initial work on signature help context
Fixes#54972
Adds `SignatureHelpContext`. This tells providers why signature help was requested
TODO:
- [ ] Better understand semantics of retrigger. Should `retrigger` be an flag instead of a `triggerReason`?
- [ ] Fix skipped test
- [ ] Add more tests for trigger reasons / trigger characters
* Fix unit test
* Make sure we retrigger sig help if it is already showing
* Add test for dismiss and re-invoke
* Extract some constants
* Extract createMockEditor
Changes how jsdoc completion works to reduce typing delays and hopefully avoid showing it for fewer false positives. Main changes
- Only show the completion item if typescript's docCommentTemplate returns something. This means that you won't see the completion item in cases like: `/** |a */` or `/**|` anymore. However in the case of `/**|`, pressing return will still complete to the empty comment as expected
- Get the snippet for the completion early so there is no flash when accepting it
The new `javascript.suggest.paths` and `typescript.suggest.paths` settings replace `typescript.quickSuggestionsForPaths`. These settings should disable all path based suggestions from js/ts
The old `quickSuggestionsForPath` setting is now marked deprecated and is not being migrated to these new settings as it has different semantics. It was originally designed just to disable quick suggestions for paths but it does not work properly when using TypeScript 2.9+
* New config to turn off TypeScript autocomplete suggestions
* add missing semicolon
* Exclude everything, even name suggestions, when suggestions disabled
