perf(vscode): search for root directory oxlint/oxfmt binaries, before searching with glob

[Sysix]

No description provided.

[Sysix]

• perf(vscode): search for root directory oxlint/oxfmt binaries, before searching with glob #17345 👈 (View in Graphite)
• main

---

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

• 0-merge - adds this PR to the back of the merge queue
• hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

[Copilot]

Pull request overview

This PR introduces a performance optimization for binary path searching in the VSCode extension by checking the workspace root's node_modules/.bin directory before performing an expensive glob search. This improves performance especially on Windows where glob operations are slow.

Key Changes

• Extracted binary search logic into a dedicated searchNodeModulesBin method
• Added fast path check using workspace.fs.stat before falling back to glob search
• Renamed parameter from defaultPattern to defaultBinaryName for clarity

---

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

[nrayburn-tech]

There’s probably a simple answer, but why do you need to search for anything other than node_modules/.bin for each of the workspace folders?

Users in a monorepo with the package installed in the root would just work. Users in a monorepo with only a single version of the package could specify the path to one of them and that would work.

This wouldn’t work for users in monorepos that want to use different versions for different packages, but is that something that really needs to be supported?

[Sysix]

My thought about searching deeper was:
Only one package in a monorepo can only use oxlint. The extension still works for them :)

This wouldn’t work for users in monorepos that want to use different versions for different packages, but is that something that really needs to be supported?

IMO this is creating too much overhead. Use one tool for the complete editor experience. Or we need to start X numbers of language server

[nrayburn-tech]

If only one package is using it within the monorepo, users could specify the path to the tool. This wouldn’t be saved in their project settings and typically committed, so I don’t think this is a problem. It’s not automatic, but it isn’t difficult or time consuming either.
Most other projects would have the package installed into one of the workspace roots.

I think those two alone cover most use cases and you wouldn’t need to use the VS Code search to find the file.

Just something to consider, I don’t think either your current approach or my suggestion is wrong. They just prioritize one behavior over the other, so it’s a trade off.

[Sysix]

Your point is valid :) I was am not sure, if we want to include a manual user defined setting for this use case.
For me, it is always "no configuration" and just start. But this is somehow complex for this user story :)