This fixes an issue where the typescript language server fails to load if multiple users launch VS Code on the same Linux machine.
Steps to reproduce:
- Log in as user1
- Launch VS Code
- Log out
- Log in as user2
- Launch VS Code
- It tries to write to files in /tmp/vscode-typescript, but that directory is not writeable because it is owned by user1
- You cannot use TypeScript intellisense
This fix namespaces the directory with the current uid so that each user will get their own.
On Windows, this shouldn't be an issue anyway since each user gets their own temp directory.
## Problem
The diagnostic collection object is set up so that it does not mutate the arrays of diagnostics you pass to it. It also does not expect or allow mutation of diagnostics that it returns.
However it it currently typed using normal arrays. This means that if an extension (such as JS/TS) wishes to use readonly diagnostics intnernally, it cannot do so without casting.
## Proposed Fix
Use `ReadonlyArray` in diagnostic collection. This should be a safe change for the `set` type methods. The changes to `get` and `forEach` have the risk of breaking the typing of some extensions, but `get` already returned a frozen array of diagnostic so trying to mutate the array itself would have resulted in runtime error.
Fixes#74633
This was the indirect cause of #74633. See that issue for an explaination of why it was problematic. In summary, updating diagnostics can retrigger code actions even if the user facing diagnostics have not actually changed
* Cleans up vs-typescript temp directoy upon VS code close
* Fixed typing errors preventing build from succeeding
* Moved deletion to the deactivate method. Added folders per extension host
* Removed yarn watch script used in testing
We'd like to know the average time that it takes to return js/ts completions so that we can identify performance regressions. The time includes both the queuing time and the actual time spent executing the command against TS server
