VS Code Performance: Optimize TypeScript Monorepos for Speed

When you’re working in a monorepo with over 50 internal packages, VS Code often turns into a sluggish, memory-hungry beast. Last month, I found myself waiting nearly 8 seconds for a simple import suggestion to resolve, which is a massive hit to developer productivity. I tried throwing more RAM at the problem, but the issue wasn't the hardware—it was the way the TypeScript language server was trying to index the entire universe of our codebase at once.

If you're dealing with similar latency, you need to rethink how your IDE processes your workspace.

Understanding VS Code Performance in Large Monorepos

The core of the problem lies in the tsserver. By default, VS Code’s language server tries to maintain a global view of all files. In a sprawling monorepo, this leads to massive memory consumption and frequent "IntelliSense is still initializing" notifications.

We initially tried to solve this by simply excluding node_modules in our tsconfig.json. While that helped slightly, the real bottleneck was our cross-package references. The language server was constantly re-parsing the entire dependency graph whenever a single file changed.

Strategies for IntelliSense Optimization

To get back to a snappy experience, you need to constrain the language server’s scope. Here are the steps that actually moved the needle for our team:

1. Leverage Project References: This is non-negotiable. By splitting your monorepo into distinct projects using composite: true in your tsconfig.json, you allow the TypeScript compiler to perform incremental builds. This prevents the language server from re-indexing the entire repo every time you save a file.
2. Exclude Unnecessary Directories: Use the exclude array in your tsconfig files aggressively. If you have dist, build, or large generated types folders, keep them out of the language server's reach.
3. Disable Workspace Symbol Indexing: If you have a massive repo, the "Go to Symbol" feature can choke on the sheer volume of files. You can turn this off for specific folders via your .vscode/settings.json:

JSON
{
  "typescript.preferences.includePackageJsonAutoImports": "off",
  "typescript.tsserver.maxTsServerMemory": 4096,
  "search.exclude": {
    "**/dist": true,
    "**/build": true
  }
}

Configuring the Language Server for Stability

If you've ever felt like your IDE is fighting you, it's usually because the tsserver has hit its memory ceiling or is stuck in an infinite loop of re-validation. We’ve found that setting the memory limit explicitly is one of the most effective ways to stabilize VS Code performance.

When you're juggling complex data flows, much like how you might manage Managing Large-Scale Data Fetching: Orchestration and Cancellation, you need your tools to be as predictable as your code. Forcing the language server to stay within a 4GB limit prevents it from triggering OS-level swapping, which is usually what causes that "frozen" feeling in the UI.

The Role of tsconfig Organization

Don't let your root tsconfig.json become a dumping ground. Instead, use a base configuration that other packages extend. This ensures that the language server only processes what is strictly necessary for the specific sub-project you are currently editing.

If you are working with Next.js, ensure your path aliases are clearly defined in the compilerOptions. I’ve seen setups where circular references in aliases cause the language server to thrash. If you're building out complex features, keep an eye on how your architecture affects IDE load, similar to the considerations for Optimizing Asset Loading: Performance, Lazy Loading, Code Splitting.

FAQ

Why is my VS Code still slow after changing tsconfig? Check your extension host. Often, other extensions (like ESLint or Prettier) conflict with the TypeScript language server. Try disabling all extensions and enabling them one by one to isolate the culprit.

Does maxTsServerMemory actually improve speed? Not directly. It prevents the language server from being killed or throttled by your operating system when it runs out of memory. It’s about stability, not raw execution speed.

Should I use "Project References" if I have a small repo? No. It adds significant configuration overhead. Only reach for project references when you start seeing consistent lag in type checking or IntelliSense resolution (usually at the 20+ package mark).

Final Thoughts

Optimizing your workspace isn't a one-time fix. As your repo grows, you'll eventually need to revisit these settings. I’m still experimenting with moving some of our heavier packages into their own separate VS Code workspaces to see if that further reduces the indexer load. Don't be afraid to prune your workspace and keep your configuration lean; your IDE is just another tool that needs maintenance, just like your production code.