Introduces the concept of a re-trigger character to the signature help provider. This is a seperate set of characters that are registered with the provider. Typing a retrigger character fires a new signature help request if signature help is already showing.
#54972
Setup a baseline tsconfig for extensions to extend. This will help make sure thatof our built-in extensions are using the recommended settings for target and so on. it also reduces duplicated code and will make updating tsconfig settings easier
A successful error computation more or less signals that the server is ready and is more reliable than waiting for the projectUpdatedInBackground signal
**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
