When the TypeScript Server Gives UpYou're deep in a complex React or Next.js project when suddenly, the editor goes dead. No syntax highlighting, no red squiggles, and hovering over variables does absolutely nothing. Then comes the dreaded notification in the bottom right corner:
TypeScript server quit unexpectedly. This may be due to a bug or very large TypeScript project.
This means tsserver—the background process powering IntelliSense, type checking, and navigation—has crashed. It usually happens when the process hits a memory ceiling (typically around 3GB by default), gets stuck in a recursive type loop, or chokes on a version mismatch between your workspace and the editor.
Quick Fix: Force a RestartDon't reach for the configuration files just yet. A simple restart often clears hung processes or temporary glitches caused by switching branches.
- Open the Command Palette (
Cmd+Shift+Pon Mac orCtrl+Shift+Pon Windows).- Type "Restart TS Server".- Select TypeScript: Restart TS Server.If the server crashes again within seconds, you're likely dealing with a resource bottleneck or a configuration conflict.
Increase the TS Server Memory LimitLarge monorepos or projects with thousands of files can easily overwhelm the default memory allocation. If you have 16GB or 32GB of RAM available, give the server some breathing room by bumping its limit to 8GB.
How to change memory settings:- Open VS Code Settings (Cmd+,).- Search for typescript.tsserver.maxTsServerMemory.- Change the value from the default to 8192.Alternatively, you can drop this directly into your .vscode/settings.json file to keep the setting project-specific:
{
"typescript.tsserver.maxTsServerMemory": 8192
}
Sync Your TypeScript VersionsVS Code ships with its own TypeScript version, but your project likely relies on a specific version installed in node_modules. Mismatches here are a classic recipe for instability. Always aim to use the workspace version.
- Open any
.tsor.tsxfile.- Look at the bottom status bar. Click the version number next to the{ }icon.- Select "Use Workspace Version" from the dropdown.This ensures the editor uses the exact compiler version your build scripts use, preventing crashes caused by newer syntax that the built-in version might not understand yet.
Exclude Heavy Folders from IndexingThe TypeScript server might be exhausting itself trying to index folders it doesn't need to touch, like dist, build, or massive documentation directories. Tightening your tsconfig.json can drastically reduce the server's workload.
Ensure your exclude array covers all non-source directories:
{
"compilerOptions": {
// ... your options
},
"exclude": ["node_modules", "dist", "build", ".next", "out", "coverage"]
}
For massive projects, you can also tell VS Code to stop watching certain patterns entirely by updating your workspace settings:
{
"typescript.tsserver.watchedFile": "dynamicPriorityPolling",
"files.exclude": {
"**/.git/objects/**": true,
"**/node_modules/*/**": true
}
}
Nuke the Cache and ReinstallSometimes a corrupted lockfile or a messy node_modules folder is the culprit. If the server is still acting up, a clean sweep is the most reliable way to reset the environment.
# Remove dependencies and lockfiles
rm -rf node_modules package-lock.json pnpm-lock.yaml yarn.lock
# Fresh install
npm install
You should also clear the TypeScript cache. On macOS, delete ~/Library/Caches/TypeScript. On Windows, clear the contents of %AppData%\Local\Microsoft\TypeScript. This forces the server to rebuild its indices from a clean slate.
Investigate the LogsStill seeing crashes? The Output panel acts as the "black box" for your editor's internal errors. It will tell you exactly why the server died.
- Open the Output tab (
View > Output).- Select TypeScript from the dropdown menu on the right.- Look forFATAL ERROR: Ineffective mark-compacts near heap limit.If the logs point to a specific file, check that file for complex recursive types or infinite loops. A single "clever" type definition can sometimes crash the entire server.

