High memory consumption in a large pnpm monorepo

[shinichy]

Extension Version

0.20260212.1

VS Code Version

1.108.1

Operating system Version

MacOS 15.7.3

Steps to reproduce

1. Open a TypeScript file within a large pnpm monorepo (observed baseline memory: ~700MB).
2. Perform a minor edit (e.g., adding a character).
3. Observe memory usage skyrocketing to ~35GB, leading to system instability or OOM.

Issue

After bisecting, I've identified that this memory regression was introduced by PR #2502.

99701-cpuprofile.pb.gz
99701-memprofile.pb.gz

[neo773]

Can reproduce on our NestJS monorepo also
It skyrockets to ~25-30GB after some navigating
Repo: https://github.com/twentyhq/twenty/

[Moltenship]

Experiencing the same thing. Here is the memory profile.

Also, it may be related to version 0.20251122.1 (previous versions works fine, aside from memory leaks when deleting files or opening a js file)

[andrewbranch]

I'm not able to reproduce this. I tried in https://github.com/twentyhq/twenty. First I navigated around and made small edits myself, and when that didn't blow things up, I had Copilot have a field day doing whatever it wanted. Note that agent mode chat opens files via the LSP and leaves them open, causing lots of projects to stay open. By the end of its edits, it had "opened" 50 files (not in tabs, but visible in our logs) across 5 projects, summing to 25k source files and over 100k exports stored in the auto-import cache. I managed to get the process to report up to 9.8 GB this way, but when a took a heap snapshot, GC ran and immediately dropped it to 8 GB. However, the actual snapshot contents showed only about 3.5 GB of in-use space, which is very close to what the process used with those 50 files and 100k auto-imports open after restarting the server. Go itself is not very good at returning unused memory to the OS; if memory spikes during a really expensive operation like find-all-references, you might not see that memory return, even if we've cleaned up internally, especially if the process isn't under memory pressure.

If someone has a repro for this, please take the following steps:

1. Enable trace logging in the typescript-native-preview (LSP) output channel. This enables cache stat logging in the other, typescript-native-preview output channel.
   
2. Once you've reached a large amount of memory usage, save a Heap profile, not an Allocations profile.
   
3. Copy the cache statistics section from our logs, e.g.

======== Cache Statistics ========
2026-02-19 17:10:03.248 [info] Open file count:       50
2026-02-19 17:10:03.248 [info] Cached disk files:  26090
2026-02-19 17:10:03.248 [info] Project count:          5
2026-02-19 17:10:03.248 [info] Config count:           6
2026-02-19 17:10:03.248 [info] Parse cache size:            25026
2026-02-19 17:10:03.249 [info] Program count:                   5
2026-02-19 17:10:03.249 [info] Extended config cache size:      1
2026-02-19 17:10:03.249 [info] Auto Imports:
2026-02-19 17:10:03.249 [info] 	Project buckets:
2026-02-19 17:10:03.249 [info] 		/users/andrew/developer/microsoft/eg/twenty/packages/twenty-emails/tsconfig.json:
2026-02-19 17:10:03.249 [info] 			Files: 75
2026-02-19 17:10:03.249 [info] 			Exports: 91
2026-02-19 17:10:03.249 [info] 		/users/andrew/developer/microsoft/eg/twenty/packages/twenty-front/tsconfig.json (dirty):
2026-02-19 17:10:03.249 [info] 			Files: 0
2026-02-19 17:10:03.249 [info] 			Exports: 0
2026-02-19 17:10:03.249 [info] 		/users/andrew/developer/microsoft/eg/twenty/packages/twenty-server/tsconfig.json (dirty):
2026-02-19 17:10:03.249 [info] 			Files: 0
2026-02-19 17:10:03.250 [info] 			Exports: 0
2026-02-19 17:10:03.250 [info] 		/users/andrew/developer/microsoft/eg/twenty/packages/twenty-shared/tsconfig.json (dirty):
2026-02-19 17:10:03.250 [info] 			Files: 0
2026-02-19 17:10:03.250 [info] 			Exports: 0
2026-02-19 17:10:03.250 [info] 		/users/andrew/developer/microsoft/eg/twenty/packages/twenty-ui/tsconfig.json (dirty):
2026-02-19 17:10:03.250 [info] 			Files: 0
2026-02-19 17:10:03.250 [info] 			Exports: 0
2026-02-19 17:10:03.250 [info] 	node_modules buckets:
2026-02-19 17:10:03.250 [info] 		/users/andrew/developer/microsoft/eg/twenty:
2026-02-19 17:10:03.250 [info] 			Files: 0
2026-02-19 17:10:03.250 [info] 			Exports: 109709
2026-02-19 17:10:03.250 [info] 		/users/andrew/developer/microsoft/eg/twenty/packages/twenty-emails:
2026-02-19 17:10:03.251 [info] 			Files: 0
2026-02-19 17:10:03.251 [info] 			Exports: 638
2026-02-19 17:10:03.251 [info] 		/users/andrew/developer/microsoft/eg/twenty/packages/twenty-front (dirty):
2026-02-19 17:10:03.251 [info] 			Files: 0
2026-02-19 17:10:03.251 [info] 			Exports: 0
2026-02-19 17:10:03.251 [info] 		/users/andrew/developer/microsoft/eg/twenty/packages/twenty-server (dirty):
2026-02-19 17:10:03.251 [info] 			Files: 0
2026-02-19 17:10:03.251 [info] 			Exports: 0
2026-02-19 17:10:03.251 [info] 		/users/andrew/developer/microsoft/eg/twenty/packages/twenty-shared (dirty):
2026-02-19 17:10:03.252 [info] 			Files: 0
2026-02-19 17:10:03.252 [info] 			Exports: 0

[shinichy]

I tried the steps above in my private repo. It appears tsgo gets stuck when this issue occurs. I'm not seeing any response in the LSP logs including custom/saveHeapProfile. Additionally, the cache statistics info is missing.

2026-02-19 21:11:53.588 [trace] Sending request 'textDocument/foldingRange - (22)'.
2026-02-19 21:11:53.656 [trace] Sending request 'textDocument/codeAction - (23)'.
2026-02-19 21:11:53.768 [trace] Sending request 'textDocument/documentSymbol - (24)'.
2026-02-19 21:12:02.002 [trace] Sending notification 'textDocument/didSave'.
2026-02-19 21:12:02.003 [trace] Sending request 'textDocument/diagnostic - (25)'.
2026-02-19 21:12:02.258 [trace] Sending notification 'workspace/didChangeWatchedFiles'.
2026-02-19 21:12:13.977 [trace] Sending request 'textDocument/documentHighlight - (26)'.
2026-02-19 21:12:14.893 [trace] Sending notification '$/cancelRequest'.
2026-02-19 21:12:14.895 [trace] Sending request 'textDocument/codeLens - (27)'.
2026-02-19 21:12:16.090 [trace] Sending notification '$/cancelRequest'.
2026-02-19 21:12:17.252 [trace] Sending request 'textDocument/documentHighlight - (28)'.
2026-02-19 21:12:17.984 [trace] Sending request 'custom/saveHeapProfile - (29)'.
2026-02-19 21:12:18.954 [trace] Sending notification '$/cancelRequest'.
2026-02-19 21:12:18.955 [trace] Sending request 'textDocument/codeLens - (30)'.

[shinichy]

@neo773 Are you able to reproduce this issue in https://github.com/twentyhq/twenty/? I couldn't reproduce this issue in the repo.

[andrewbranch]

@shinichy could you try out #2855 and see if that improves things for you?

[shinichy]

@andrewbranch It seems to help slightly. The memory leak is slower now, but it doesn't fix the root cause. The tsgo LSP process still hangs, and memory usage eventually hits ~30GB. I debugged the process and found that it gets stuck at extractFromFile(entrypoint) in internal/ls/autoimport/registry.go.

I asked AI about this issue and here's the response.

Here’s what’s going on and how to fix it.

---

Why extractFromFile(entrypoint) can hang

Several things combine so that a single call (or a few calls) can run for a very long time and look like they “never finish.”

1. Unbounded work per entrypoint (main cause)

extractFromFile ends up calling the checker’s GetExportsOfModule (in extract.go around 176 and 192). That goes into getExportsOfModuleWorker in the checker, which:

• Resolves the module with resolveExternalModuleSymbol
• For every export * from "...", calls resolveExternalModuleName and then recursively visits the resolved module’s exports

When resolving a module, the checker loads the file via the program:

	if resolvedModule.IsResolved() && (resolutionDiagnostic == nil || resolutionDiagnostic == diagnostics.Module_0_was_resolved_to_1_but_jsx_is_not_set) {
		sourceFile = c.program.GetSourceFileForResolvedModule(resolvedModule.ResolvedFileName)
	}

So for each export *, the checker loads that target file (and binds it). There is no limit on how many files one entrypoint can pull in. In a monorepo or a package with lots of re-exports (e.g. barrel files that export * from many modules), a single entrypoint can trigger loading hundreds or thousands of files. That gives both huge runtime and huge memory (all those ASTs stay in memory), which matches the “never finishes” and high memory you’re seeing.

2. No cancellation inside extraction

Cancellation is only checked between entrypoints, not inside the extraction or the checker:

			for _, entrypoint := range aliasResolver.rootFiles {
				if ctx.Err() != nil {
					return
				}

				fileExports := extractor.extractFromFile(entrypoint)

So once extractFromFile(entrypoint) starts, it runs to completion with no way to cancel, even if the request is cancelled or the LSP is shutting down. If that one entrypoint triggers a huge export chain, the process looks stuck.

3. Very large number of entrypoints when there is no exports field

When a package does not have an "exports" field in package.json, the resolver falls back to scanning the whole package directory and treats (almost) every file as an entrypoint:

	otherFiles := vfs.ReadDirectory(
		r.host.FS(),
		r.host.GetCurrentDirectory(),
		packageJson.PackageDirectory,
		extensions.Array(),
		[]string{"node_modules"},
		[]string{"**/*"},
		nil,
	)
	// ...
	for _, file := range otherFiles {
		// ...
		result.Entrypoints = append(result.Entrypoints, r.createResolvedEntrypointHandlingSymlink(...))
	}

In a large pnpm monorepo you can have many such packages, so the total number of entrypoints can be very high. Each one gets an extractFromFile call that can itself pull in many more files via export *, so total work and memory grow quickly.

4. Checker not tied to request context

checker.NewChecker(aliasResolver) is called without a context. The checker’s internal cancellation (wasCanceled / ctx) is not wired to the LSP request context, so even if the checker supported cancellation, it wouldn’t react to the same ctx that’s checked between entrypoints.

---

Summary

• Primary cause: One (or a few) entrypoints cause the checker to follow all export * chains and load every resolved file, with no bound on how many files that can be. In big monorepos or packages with many re-exports, that becomes a huge amount of work and memory and looks like a hang.
• Contributing factors: No cancellation inside extractFromFile (or the checker), and packages without "exports" producing a large number of entrypoints.

---

Suggested directions for a fix

1. Limit or bound export resolution during extraction
   For auto-import, you may not need full re-export resolution. Options:

   • Cap the depth or number of files loaded when following export * in this code path, or
   • Skip or shorten export * resolution for node_modules / auto-import (e.g. only use direct exports of the entrypoint).

2. Respect context inside extraction

   • Pass ctx into the extraction path and check ctx.Err() in the inner loop (e.g. around each file or each batch of symbols), and/or
   • Create the checker with a context and have the checker check it in the hot paths (e.g. in getExportsOfModuleWorker / visit and when loading files) so that long-running work can be aborted.

3. Limit entrypoints when there is no exports field
   For packages without "exports", avoid treating every file under the package as an entrypoint (e.g. only use main/index or a small set of well-known entry files, or cap the number of entrypoints per package).

4. Reuse / share work
   PR Share package.json cache and skip collecting failed lookup locations in auto-imports #2855’s direction (sharing package.json cache and skipping failed lookup locations) helps reduce redundant work and memory; combining that with the above (bounded export resolution, cancellation, and fewer entrypoints) should address both the “never finishes” behavior and the high memory usage you’re seeing in issue High memory consumption in a large pnpm monorepo #2780.

[andrewbranch]

Can you share what package/file it's getting stuck on? It would also be helpful to see bucket.DependencyNames and len(bucket.Paths) if you're debugging. Better yet, if you can share your pnpm-lock or package.json dependencies, I can see if I can repro myself.

[shinichy]

Unfortunately, I can't share the code as it's in a private company repo. bucket.DependencyNames is nil and len(bucket.Paths) is 0. I'll try to create a public repo with a similar dependency graph to reproduce this issue.

[justinsmid]

I am also experiencing excessive memory usage in my project. Here's my stats from when the tsgo process was up to 45.9GB:

2026-02-23 10:51:44.580 [info] 
======== Cache Statistics ========
2026-02-23 10:51:44.580 [info] Open file count:        9
2026-02-23 10:51:44.580 [info] Cached disk files:  19515
2026-02-23 10:51:44.580 [info] Project count:          3
2026-02-23 10:51:44.581 [info] Config count:           5
2026-02-23 10:51:44.581 [info] 
2026-02-23 10:51:44.581 [info] ======== Cloning snapshot 780 ========

And the heap profile: 1410981-1771840884787-heapprofile.pb.gz

My project is also private, though I think Jake Bailey should still have access to our repo from helping us out in the past.