fix(vscode): Prevent timeout in binary search for large pnpm monorepos by MIreland · Pull Request #17580 · oxc-project/oxc

MIreland · 2026-01-02T01:43:16Z

AI Disclaimer:

The code changes in this PR was written entirely by Cursor.

I opened this issue: #17578

Then I started debugging the extension locally, adding logs with cursor and tracking down where my plugin was failing to instantiate.

I walked through the entire process with cursor, feeding it logs and manually walking through several permutations of trial and error on my local instance of vscode. The code and traversal patterns themselves were written by AI.

I have a large local pnpm monorepo that does NOT work with the published vscode extension. It does work with this branch.

Problem

This is a fix for #17578

The VS Code extension was timing out when searching for binaries in large pnpm monorepos. The workspace.findFiles call with a recursive pattern **/node_modules/.bin/${defaultPattern} was searching through potentially thousands of nested node_modules directories, causing indefinite hangs.

Solution

Implemented a hybrid approach that prioritizes fast file system operations and only uses findFiles as a last resort with timeout protection:

Caching: Results are cached to avoid repeated searches
Fast path checks: Checks root node_modules/.bin/ in each workspace folder first
Depth-limited file system search: Uses recursive file system operations (max depth 3) to search parent directories
Timeout protection: Wraps findFiles with a 5-second timeout using Promise.race to prevent indefinite hanging

Changes

Added searchBinaryInNodeModules() method for depth-limited file system search
Added findFilesWithTimeout() helper method with timeout protection
Refactored searchBinaryPath() to use progressive search strategy
Added cache invalidation when workspace folders change

Performance Benefits

No indefinite hangs: Timeout ensures we never wait forever
Fast path: File system operations are much faster than findFiles in large monorepos
Graceful degradation: Falls back to findFiles only if needed, with timeout protection
Depth limiting: Prevents deep recursion in very large monorepos

Testing

Verified behavior remains the same for existing scenarios
Works in both npm/yarn and pnpm monorepos
Handles binaries in root, nested, and workspace-specific locations

Copilot

Pull request overview

This PR addresses timeout issues in the VS Code extension when searching for binaries in large pnpm monorepos by implementing a hybrid search strategy with caching, fast-path file system operations, depth-limited searching, and timeout protection.

Key Changes:

Implements a three-tier progressive search strategy: direct file system checks, depth-limited recursive search, and timeout-protected findFiles fallback
Adds binary path caching to avoid repeated expensive searches
Introduces timeout protection (5 seconds) for the workspace.findFiles API to prevent indefinite hangs

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

editors/vscode/client/ConfigService.ts

- Fix cache check to use Map.has() instead of !== undefined - Clear cache when binary path settings change in onVscodeConfigChange - Fix comment accuracy about search direction - Fix misleading comment about deep recursion - Make Windows drive letter regex case-insensitive - Skip .pnpm directories in file system search - Fix timeout leak by clearing timeout ID in finally block - Improve error handling in catch block

connorshea · 2026-01-02T01:51:06Z

Based on the PR description I presume this was - at least in large part - generated using AI tooling.

Please update the PR description to note any and all AI usage in accordance with our policy, preferably including models/tools used and a confirmation that you have personally reviewed the code generated and ensured it works/makes sense: https://oxc.rs/docs/contribute/introduction.html#ai-usage-policy

If the PR description is not updated in a timely manner, we will opt to close this PR to avoid maintainer fatigue and prevent spending too much time on contributions not thoroughly reviewed by the contributor.

connorshea · 2026-01-02T01:59:20Z

It may also be worth checking #17345 to see if that fixes the problem for your large monorepo as an alternative, although it will mostly depend on Sysix/camc's preference here - assuming both fix the problem adequately.

MIreland · 2026-01-02T01:59:35Z

@connorshea Added an AI disclaimer with context to the description.

connorshea · 2026-01-02T02:01:12Z

@connorshea Added an AI disclaimer with context to the description.

Thank you!

connorshea · 2026-01-02T02:03:17Z

editors/vscode/client/ConfigService.ts

+    pattern: RelativePattern,
+    exclude: string | null,
+    maxResults: number,
+    timeoutMs: number = 5000,


I know of some cases (mainly networked drives) where searching for files could take at least a few seconds, and so we may want to consider bumping this up a bit. We could make it configurable, but it's not my preference.

MIreland · 2026-01-02T02:08:19Z

#17345 also fixes the issue if oxfmt is installed. I don't currently plan to use oxfmt, although I'll stick it in the node_modules if I need to to make the extension work 😂

I'll call this out in that PR as well.

connorshea · 2026-01-02T02:14:25Z

although I'll stick it in the node_modules if I need to to make the extension work 😂

lol I guess that's okay as a temporary workaround until we ship a fix, but yeah it's definitely not intentional that the extension locks up for users with only oxlint installed

connorshea · 2026-01-02T02:25:14Z

Oh also #17511 probably improves the handling of a missing oxfmt binary and has already been merged, will go out in the release on Monday.

MIreland · 2026-01-02T02:48:25Z

At first glance it doesn't look like that code would help handle the situation when .findFiles times out, just the situations where it doesn't. But I'm happy to verify come Monday!

Sysix

Thanks for working on this 🫶 Did you try to use tinyglobby npm package and avoid workspace.findFiles completely? I am confused why this is really slow.

Sysix · 2026-01-02T14:02:16Z

editors/vscode/client/ConfigService.ts

+
+      // Skip .pnpm directories to avoid traversing into pnpm's internal structure
+      // Check if we're inside a .pnpm directory path
+      if (


I do not like it, that we have a special check for only .pnpm.
Can the search really ends up in a .pnpm directory?

Sysix · 2026-01-02T14:03:38Z

editors/vscode/client/ConfigService.ts

+        }
+
+        // Check with .exe extension on Windows
+        if (process.platform === "win32") {


For windows, we do not use the .exe. Depending on the package manager, there is no exe.
That's why we use shell: true for windows, to target the same binary :)

oxc/editors/vscode/client/tools/lsp_helper.ts

Lines 26 to 38 in f02c0e7

: {

// On Windows with shell, quote the command path to handle spaces in usernames/paths

command: isWindows ? `"${path}"` : path,

args: ["--lsp"],

options: {

// On Windows we need to run the binary in a shell to be able to execute the shell npm bin script.

// Searching for the right `.exe` file inside `node_modules/` is not reliable as it depends on

// the package manager used (npm, yarn, pnpm, etc) and the package version.

// The npm bin script is a shell script that points to the actual binary.

// Security: We validated the user defined binary path in `configService.searchBinaryPath()`.

shell: isWindows,

env: serverEnv,

},

Sysix · 2026-01-02T14:05:54Z

editors/vscode/client/ConfigService.ts

+   * Searches for a binary in node_modules/.bin directories using file system operations.
+   * This is much faster than workspace.findFiles in large monorepos.
+   * Limits search depth and scope to avoid timeouts.
+   * Note: This method searches upward from the start path toward the filesystem root.


I do not like this too. We have validateSafeBinaryPath which explicit disallow parent directory access.

Sysix · 2026-01-02T14:07:09Z

editors/vscode/client/ConfigService.ts

+    maxResults: number,
+    timeoutMs: number = 5000,
+  ): Promise<Uri[]> {
+    const searchPromise = workspace.findFiles(pattern, exclude, maxResults);


workspace.findFiles has a fourth parameter to cancel the search. Use this parameter instead of Promise.race :)

Sysix · 2026-01-02T14:07:45Z

editors/vscode/client/ConfigService.ts

-        1,
+      // Check cache first
+      const cacheKey = `auto:${defaultPattern}`;
+      if (this.binaryPathCache.has(cacheKey)) {


searchBinaryPath will only be called at the start of the extension. Can you tell me why a cache is needed?

Sysix · 2026-01-02T14:10:01Z

editors/vscode/client/ConfigService.ts

+        return result;
+      } catch (error) {
+        // Timeout or other error - log and cache undefined to avoid retrying
+        // Note: Error logging is intentionally minimal to avoid noise in production


can we add a window.showErrorMessage so the user knows the search failed?
Probably suggest setting the oxc.path.* configuration to avoid automatic search

I'm just going to shut this PR down in favor of #17345, which works also works for my giant monorepo.

Sysix · 2026-01-02T14:13:18Z

editors/vscode/client/ConfigService.ts

+
+      // Fast path: Check common locations first using file system operations
+      // This is much faster than recursive findFiles in large monorepos
+      const workspaceFolders = Array.from(this.workspaceConfigs.keys());


The old implementation used only the first workspace folder. I guess this could lead to performance problems too. Specially with setups like in this example:
#17515

MIreland · 2026-01-02T16:14:09Z

I'm going to close this in favor of #17345

Prevent timeout in binary search

d42873a

Copilot AI review requested due to automatic review settings January 2, 2026 01:43

MIreland requested a review from camc314 as a code owner January 2, 2026 01:43

github-actions bot added A-editor Area - Editor and Language Server C-bug Category - Bug labels Jan 2, 2026

Copilot started reviewing on behalf of MIreland January 2, 2026 01:43 View session

MIreland mentioned this pull request Jan 2, 2026

linter: vscode extension findFiles timeout #17578

Closed

Copilot AI reviewed Jan 2, 2026

View reviewed changes

MIreland mentioned this pull request Jan 2, 2026

perf(vscode): optimize binary search for pnpm monorepos #17552

Closed

[autofix.ci] apply automated fixes

9f2f411

connorshea requested a review from Sysix January 2, 2026 01:59

connorshea reviewed Jan 2, 2026

View reviewed changes

Sysix reviewed Jan 2, 2026

View reviewed changes

Sysix mentioned this pull request Jan 2, 2026

VS Code extension is not registered as a formatter for TypeScript, shows for a long time or forever #17586

Closed

MIreland closed this Jan 2, 2026

	: {
	// On Windows with shell, quote the command path to handle spaces in usernames/paths
	command: isWindows ? `"${path}"` : path,
	args: ["--lsp"],
	options: {
	// On Windows we need to run the binary in a shell to be able to execute the shell npm bin script.
	// Searching for the right `.exe` file inside `node_modules/` is not reliable as it depends on
	// the package manager used (npm, yarn, pnpm, etc) and the package version.
	// The npm bin script is a shell script that points to the actual binary.
	// Security: We validated the user defined binary path in `configService.searchBinaryPath()`.
	shell: isWindows,
	env: serverEnv,
	},

Uh oh!

Conversation

MIreland commented Jan 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

AI Disclaimer:

Problem

Solution

Changes

Performance Benefits

Testing

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

connorshea commented Jan 2, 2026

Uh oh!

connorshea commented Jan 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MIreland commented Jan 2, 2026

Uh oh!

connorshea commented Jan 2, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MIreland commented Jan 2, 2026

Uh oh!

connorshea commented Jan 2, 2026

Uh oh!

connorshea commented Jan 2, 2026

Uh oh!

MIreland commented Jan 2, 2026

Uh oh!

Sysix left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MIreland commented Jan 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

MIreland commented Jan 2, 2026 •

edited

Loading

connorshea commented Jan 2, 2026 •

edited

Loading