refactor(oxlint/lsp): lint tsgolint in the same thread

[Sysix]

This PR comes from different use cases, and I hope I did not have a wrong understanding about spawning child.

std::spawn in tokio runtime

Because the LSP is in a tokio runtime, we should avoid spawning threads with std, instead using tokio::spawn.
I try to work already with tokio::spawn in the oxc_language_server side with #23768
So this will spawn the complete diagnostic path into one separate process. We already need to wait for the tsgolint result, so spawning one thread there is suboptimal(?)

disable_directives_map lock for the whole thread spawn

Asked Codex Terra 5.6 where a lock could be generated in #23768, and it found this long-lock.

The problematic lock scope is tsgolint.rs line 403: the stdout-reader takes disable_directives_map.lock() before iterating the entire TsGoLintMessageStream. The diagnostic reader therefore serializes all type-aware runs, including code actions. This is especially visible after introducing concurrent diagnostics.

tsgolint process still running

Some users did report that many tsgolint processes are still running, even if not typed. My first guess is these are zombie processes and can be safely killed.
I did not find the exact issue but oxc-project/oxc-vscode#264 should be good enough for a reference.

[Sysix]

• refactor(oxlint/lsp): lint tsgolint in the same thread #24670 👈 (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 changes, fast-track this PR to the front of the merge queue

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

Refactors the tsgolint integration used by oxlint/LSP so diagnostics are read and processed in the calling thread instead of being handled via additional worker threads.

Changes:

• Removes the nested thread setup previously used to drain tsgolint stdout and collect diagnostics.
• Processes the tsgolint message stream synchronously, then waits for the child process and returns diagnostics/errors.

[codspeed-hq]

Merging this PR will not alter performance

✅ 5 untouched benchmarks
⏩ 71 skipped benchmarks¹

---

_{Comparing 07-19-refactor_oxlint_lsp_lint_tsgolint_in_the_same_thread (ca55327) with main (dd18383)²}

Footnotes

1. 71 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on main (0ed53f1) during the generation of this report, so dd18383 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

crates/oxc_linter/src/tsgolint.rs:523

• lint_source no longer waits on the spawned tsgolint child or checks its exit status. Calling kill() without wait() can still leave a zombie process on Unix, and failures (non-zero exit) can now be silently ignored even if stdout parsing succeeded.

        // Kill the child process if it's still running to avoid zombie processes
        let _ = child.kill();

        diagnostics