vscode: TypeScript's dependency on electron limits the heap size to a point that breaks monorepos, and tsserver-bridge is no longer a workaround

Bug Report

Electron enforces a heap memory limit (due to pointer compression) that causes typescript to crash in large mono-repo. This was originally reported here, and then on the electron side here. One common workaround is to use tsserver-bridge to cause vscode to launch the typescript editor service in node rather than electron. Starting in typescript 4.6, it appears that the tsserver-bridge workaround no longer works.

Error when using tsserver-bridge:

Info 0    [09:17:36.144] Starting TS Server
Info 1    [09:17:36.145] Version: 4.6.4
Info 2    [09:17:36.145] Arguments: /my/path/to/node /my/path/to/.vscode/typescript/lib/_tsserver.js --useInferredProjectPerProjectRoot --enableTelemetry --cancellationPipeName /var/folders/l1/qrb13dbx3l3_wjlh4kgxnpm80000gn/T/vscode-typescript501/8d65dce0fd217a13c1cc/tscancellation-f05eabd1e2d0ae3f8300.tmp* --logVerbosity verbose --logFile /my/path/to/Code/logs/20220509T134031/exthost1/vscode.typescript-language-features/tsserver-log-Y6lofO/tsserver.log --locale en --noGetErrOnBackgroundUpdate --validateDefaultNpmLocation --useNodeIpc
Info 3    [09:17:36.145] Platform: darwin NodeVersion: 16 CaseSensitive: false
Info 4    [09:17:36.145] ServerMode: undefined syntaxOnly: false hasUnknownServerMode: undefined
Info 5    [09:17:36.149] Binding...
Info 6    [09:17:36.153] event:
    {"seq":0,"type":"event","event":"typingsInstallerPid","body":{"pid":28855}}
Err 7     [09:17:36.163] Exception on executing command unknown:

    process.send is not a function

    TypeError: process.send is not a function
        at IpcIOSession.writeMessage (/my/path/to/.vscode/typescript/lib/_tsserver.js:177001:29)
        at IpcIOSession.Session.send (/my/path/to/.vscode/typescript/lib/_tsserver.js:172938:22)
        at IpcIOSession.Session.event (/my/path/to/.vscode/typescript/lib/_tsserver.js:172947:22)
        at IpcIOSession.IOSession.event (/my/path/to/.vscode/typescript/lib/_tsserver.js:176966:48)
        at NodeTypingsInstaller.event (/my/path/to/.vscode/typescript/lib/_tsserver.js:176926:31)
        at Immediate.<anonymous> (/my/path/to/.vscode/typescript/lib/_tsserver.js:176776:71)
        at processImmediate (node:internal/timers:464:21)

Unfortunately, tsserver-bridge is no longer supported (author thinks it is no longer required since you can adjust heap size, but electron limits heap size because it implements pointer compression).

Electron has been so far unwilling to provide builds that disable pointer compression, and even if they did, vscode would need to begin leveraging it.

🔎 Search Terms

tsserver-bridge, heap limit, memory limit, process.send

🕗 Version & Regression Information

This changed between versions 4.5.4 and 4.6.4

🙁 Actual behavior

Large mono repos hit the memory limit and tsserver-bridge is not a workaround

🙂 Expected behavior

Allow tsserver-bridge to work or get off of electron

About this issue

Original URL
State: closed
Created 2 years ago
Reactions: 1
Comments: 22 (13 by maintainers)

Most upvoted comments

Yes that sounds like the correct approach. A few points:

For security reasons, we can’t just use this value from the workspace settings (because it could point to an evil version of node). You can take a look at how the php.validate.executablePath setting for a similar example of how this should work
I’d even say we only want the new setting to be configurable as user setting and never as a workspace setting. We don’t expect many users to configure it and if they do, they likely want the custom version of node to always be used
We need to log when a custom node version is being used (we already log the TS version). This will help us track down if a custom node version is causing issues

mjbvz on Jun 9, 2022

We discussed this today and decided VS Code should possibly let users opt into spawning TS Server in their own installed version of Node (and inform TS Server so it can communicate over STDIO as before, IIUC). @mjbvz was going to see if other language extensions have run into something similar. Matt, can I transfer this issue to VS Code for now?

andrewbranch on May 25, 2022