Type-erase the shared LSP server future so CLI and NAPI reuse one async state machine. This removes duplicate LSP machinery and reduced the measured release binary by about 1.3 MiB.
AI assistance was used to implement this change.
> ## Pull request overview
>
> This PR updates the language server’s dynamic worker startup paths to surface `ClientMessage` warnings/errors to the client when a worker is created/started dynamically, and adds a regression test for single-file mode.
>
The newly created `ClientMessage` will now be passed into `Backend` and
sent to the client.
There is atm no real implementation in `oxlint` & `oxfmt`, but the LSP
integration is done (expect dynamic worker creation, see #25407).
Added a new `ToolBuildResult` struct, so an optional `ClientMessage` can
be passed to `Backend` (in a later PR).
This allows us later to send the custom message to the clients interface
when some config errors happened on the (re)creation.
There is no message sent yet, this will be integrated in another PR too.
This PR is just the base for the `ToolInterface`.
Working on the stack https://github.com/oxc-project/oxc/pull/23768 I created a local test with many responses in a quick time. This code change did resolve the issue.
Auto-merge because it only effects tests, even if not perfect :)
Autogenerated by Codex AI Agent 🤖
Some clients can send code actions for documents, which are not opened and already analyzed with a lint process.
A good example is the IntelliJ plugin, which allows the "fix all" code action from the file explorer.
> This PR refactors the language-server → tool code-action API to pass a single request struct (including an “is document open” flag), enabling the oxlint LSP linter to avoid re-running lint for code-action requests when the document is already open (and presumably already linted/cached).
This is mostly needed for https://github.com/oxc-project/oxc/pull/23768
When a user defined a custom config path, like `fmt.configPath` or `configPath`, the watch pattern returned the same path.
VS Code does not respect this as a valid pattern and does not watch for files defined like `./define-config.ts`.
Resulting into an LSP client, which will not send a watched-file-change requests to the server, when the user edited an important config path.
Fixes#23314
## Summary
- add an LSP-specific UTF-8 byte offset to `Position` converter
- use it for oxfmt formatter `TextEdit` ranges
- route oxlint LSP positions through the same converter
## Details
The existing conversion used the shared rope helper, which treats
Unicode line
and paragraph separators as line breaks. That is correct for some
JavaScript
source-location semantics, but LSP only treats CR, LF, and CRLF as line
breaks.
This keeps the shared rope helper unchanged and isolates the
protocol-specific
behavior in `oxc_language_server`.
## Tests
- `cargo fmt --all`
- `cargo test -p oxc_language_server position --lib`
- `cargo test -p oxfmt --lib lsp::server_formatter`
- `cargo test -p oxlint --lib lsp::error_with_position`
- `cargo clippy -p oxc_language_server -p oxfmt -p oxlint --lib --tests
--no-deps -- -D warnings`
- `git diff --check`
---------
Co-authored-by: xiaokhkh <10765730+xiaokhkh@users.noreply.github.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: Sysix <sysix@sysix-coding.de>
When editors are sending absolute config paths like `configPath: "/home/user/.../.oxlintrc.json`, the relative information is not needed.
Do not know how editors will handle absolute path with a relative base URI. To make sure, everyone knows how to look it up, absolute patterns are not tied to base URI.
`init_watchers` was returning a `Vec<Registration>`, this was needed where the Worker need to manager multiple tools. Now it only owns one tool and can use `Option<Registration>` instead.
Because `DiagnosticMode` can only be evaluated with the `ClientCapabilities` from the editor, we need to delay the creation of the dynamic worker.
It works atm, because we know `oxfmt` is always `DiagnosticMode::None`, but I have plans to make `oxlint` compatible with the `ManagerMode::DynamicWithWorkspaces`.
Bonus: The dynamic worker is only created once, use `OnceCell` instead of a lock
closes https://github.com/oxc-project/oxc-vscode/issues/180
`oxfmt` config architecture allows running a second instance of the formatter. This worker is responsible now for single file mode and files outside the current workspace.
> In `oxfmt` LSP context, user want to use the server without a context of a project.
They want just open a file with `code /Users/local-settings/file.json`, which we already supported with the `single_file_mode` flag.
But they also expect to format such files when you have already opened a project.
It will not create watchers for this manager because they would be too expensive, atm the architecture only works with the root path of the workspace. In the example of the dynamic workspace, it would watch the complete file system.
This will "break" the single file mode in `oxfmt --lsp`, when a user edits the oxfmt config on the same level where an edited file is formatted.
Tested it with VS Code and WSL2 (linux) and Win10 native. Beside #21654 everything works as expected 🥳
This was a performance PR at first, but I am not sure if this will be noticeable.
Downsides first:
- We now always write to the file system, even if a worker could not be found
Upsides:
- Editing a file from another workspace, and then requesting formatting, did result into an invalid state (the in memory state was not set yet)
- on `textDocument/didOpen` & `textDocument/didSave` we avoid the worker lock completely if
- Diagnostic mode is "none" (for `oxfmt`)
- Diagnostic mode is "pull" (for `oxlint`, where the client does not support `textDocument/diagnostic` request)
Thought that the self reference will be used in a later stack, but the current implementation of the dynamic workspace worker looks good at the moment.
Little refactoring
Added logic for dynamic worker when first initializing the watch patterns. These will never change, not like other watch pattern which can be later be changed with `workspace/didChangeConfiguration`.
Dynamic Workers are not linked into this method, because it is not directly an LSP concept, instead something the LSP server needs to handle internally.
`workspace/executeCommand` is respected too. These are the only missing code paths :)
This method was used to create unique watcher IDs for each tool.
Because `oxc_language_server::run_server` now accepts only one tool, we can safely remove this method.
First code for the `DynamicWithWorkspaces`. This is just for `get_worker_for_uri` code path. File watchers and more are not supported atm.
This is all behind a test flag atm, later we use it inside `oxfmt`
The language server needs to support "modes" of workspaces management.
This could probably be refactored out later when we want to align `oxlint` with `oxfmt`.
The main reason why this check of "modes" is needed:
In `oxfmt` LSP context, user want to use the server without a context of a project.
They want just open a file with `code /Users/local-settings/file.json`, which we already supported with the `single_file_mode` flag.
But they also expect to format such files when you have already opened a project.
Created the enum so we can switch between 3 modes. One is not used atm, but simplifies the logic a bit. Maybe `oxlint` will drop its mode. VS Code will not request diagnostics in single file mode. Need to check what other editors do.
> Adds a `ResolvedPath` wrapper and new fixtures/tests intended to validate consistent path resolution across mixed-case `file://` URIs (notably from VS Code), to avoid mismatches when mapping URIs to filesystem/workspace entities.
Canonicalized only on windows macOS where case-sensitive file are present.
Not only linux, because `Text.txt` and `test.txt` in the same directory are different files.
This does not fix the stale diagnostics, but we now have at least a clean state on the linter side, when the document changed, but code actions are requested without a diagnostic request before.
Was originally found by https://github.com/oxc-project/oxc/pull/19793 and moved into an own PR for here.
Thank you, @wagenet
> ## Pull request overview
>
> Refactors the `oxc_language_server` LSP implementation to operate with a single `Tool`/`ToolBuilder` instead of managing multiple tools per workspace, simplifying worker creation and capability wiring.
The `Backend` struct in `backend.rs` was directly owning and managing all worker lifecycle logic — including the worker list, single-file mode flag, tool builders, dynamic worker creation, and workspace folder transitions — making the struct unwieldy and difficult to reason about.
## Changes
**New `WorkerManager` struct (`worker_manager.rs`)**
- Owns `workers: RwLock<Vec<WorkspaceWorker>>`, `single_file_mode: AtomicBool`, and `tool_builders: Arc<[Box<dyn ToolBuilder>]>`
- Manages two modes: *workspace mode* (root URI or workspace folders provided at `initialize`; workers created once and updated only on `didChangeWorkspaceFolders`) and *single-file mode* (no workspace provided; workers created dynamically on `didOpen` and torn down on `didClose`)
- Hosts all worker-lookup logic: `find_worker_for_uri`, `get_parent_dir_uri`, `assert_workspaces_are_valid_paths`
- Adds `WorkerGuard<'_>` — a RAII type that holds the read lock and dereferences to the matched `WorkspaceWorker`, returned by the new `get_worker_for_uri` async helper
- Encapsulates single-file-mode operations: `ensure_worker_for_file_uri` (returns `Option<Vec<Registration>>` for caller to forward to client), `try_shutdown_empty_workspace` (takes `open_uris` snapshot from caller to avoid cross-lock deadlocks)
- Encapsulates `update_workspace_folders` — the write-lock phase of `didChangeWorkspaceFolders` that handles mode transitions and worker extraction
**Simplified `Backend` (`backend.rs`)**
- Replaces the three fields `workspace_workers`, `single_file_mode`, `tool_builders` with a single `worker_manager: WorkerManager`
- All LSP handlers that look up a single worker now use `get_worker_for_uri` instead of the previous two-step `read_workers()` + `find_worker_for_uri` pattern:
```rust
// Before
let workers = self.worker_manager.read_workers().await;
let Some(worker) = WorkerManager::find_worker_for_uri(&workers, &uri) else { return; };
// After
let Some(worker) = self.worker_manager.get_worker_for_uri(&uri).await else { return; };
```
- All LSP handlers delegate worker lookup and lifecycle to `WorkerManager`; only client I/O (diagnostics publishing, capability registration) stays in `Backend`
```rust
// Before
pub struct Backend {
tool_builders: Arc<[Box<dyn ToolBuilder>]>,
workspace_workers: Arc<RwLock<Vec<WorkspaceWorker>>>,
single_file_mode: AtomicBool,
// ...
}
// After
pub struct Backend {
worker_manager: WorkerManager,
// ...
}
```
Workers are never cloned; ownership is transferred via `swap_remove` / `drain` as before.
<!-- START COPILOT CODING AGENT TIPS -->
---
⚡ Quickly spin up Copilot coding agent tasks from anywhere on your macOS or Windows machine with [Raycast](https://gh.io/cca-raycast-docs).
> ## Pull request overview
>
> Refactors the language-server tool interface to pass a single `TextDocument` struct (uri + language id + optional text) instead of multiple parameters, and updates LSP backend/worker call sites and tests accordingly.
>
> **Changes:**
>
> * Introduce `TextDocument` in `oxc_language_server` and thread it through `Tool`/`WorkspaceWorker` APIs.
>
> * Update `LSPFileSystem` to provide `get_document()` and migrate backend/worker/tool implementations to use it.
>
> * Update LSP-related tools/tests in `apps/oxlint` and `apps/oxfmt` to the new API.
Added LSP support for Client connections without a workspace. Typically, it happens when the user just opens the file (e.g. `vscode /path/to/file.js` instead of `vscode /path/to/workspace`). Then the client will not send a workspace Folder or a root URI.
Before this PR the LSP backend did not create a worker when root URIs are provided. Requests for formatting or diagnostics did not find a worker and returned silently no result.
In this PR we try to create workspace folders on the fly and try to shut them down when no longer needed.
Currently, we use the directory of the file as a root URI for workspace. We can later improve this logic for search for a git project or config file. I just like to have the ground steps here to improve them later :)
This method is nice because we automatically have config search support by the tools. We should improve the config search for them in this single file mode. I just added basic testing in later PRs.
-----
When an LSP client initializes without providing any workspace folders or root URI, the language server previously created no workers and silently ignored all file notifications. This implements proper single-file mode support entirely within `oxc_language_server` — no changes to `apps/oxfmt` or `apps/oxlint`.
## Changes
- **`single_file_mode: AtomicBool`** on `Backend` — set to `true` in `initialize` when neither `workspace_folders` nor `root_uri` is provided.
- **`ensure_worker_for_file_uri`** — on `textDocument/didOpen`, if in single-file mode and the URI is `file://`, a `WorkspaceWorker` is created dynamically for the file's parent directory. Uses a read-lock fast path, requests `workspace/configuration` when the client supports it, double-checks under write lock, then starts the worker and registers watchers.
- **`try_shutdown_empty_workspace`** — on `textDocument/didClose`, if no other open files map to the same workspace, the worker is shut down, removed, push diagnostics cleared, and watchers unregistered.
- **`did_change_workspace_folders` mode transitions** — when workspace folders are added while in single-file mode, the server exits single-file mode and shuts down all dynamically-created workers before adding the explicit workspace workers. When all workspace folders are removed and no new ones are added, the server enters single-file mode so subsequent `didOpen` calls create workers dynamically again.
- **Non-`file://` schemes** (e.g. `untitled://`, `vscode-userdata://`) are skipped — no worker is created for them in single-file mode.
## Behavior
```
Client initializes with no workspaceFolder / rootUri
→ single_file_mode = true, workers = []
textDocument/didOpen file:///home/user/project/foo.ts
→ workspace worker created for file:///home/user/project/
textDocument/didOpen file:///home/user/project/bar.ts
→ same worker reused (path prefix match)
textDocument/didClose file:///home/user/project/foo.ts
→ sibling bar.ts still open → worker kept
textDocument/didClose file:///home/user/project/bar.ts
→ no open files left → worker shut down & removed
workspace/didChangeWorkspaceFolders (add folder)
→ exit single-file mode, shut down single-file workers,
create explicit workspace worker
workspace/didChangeWorkspaceFolders (remove last folder)
→ enter single-file mode
```
<!-- START COPILOT CODING AGENT TIPS -->
---
💬 Send tasks to Copilot coding agent from [Slack](https://gh.io/cca-slack-docs) and [Teams](https://gh.io/cca-teams-docs) to turn conversations into code. Copilot posts an update in your thread when it's finished.
Little bit of refactoring for later PRs.
Pass the complete context to the tool trait so other parameter of it can be used like `diagnostics` or trigger kind.
There is a little optimization that can be done. When requesting a code action from trigger-kind=automatic or with a diagnostic, we can skip the cache-fallback of linting the file. Mostly the file is linted already by another thread.
> ## Pull request overview
>
> Updates the language server’s `LanguageId` trait documentation to clarify how formatters should determine the language for a document, emphasizing use of the LSP-provided `language_id`.
> This PR updates workspace-worker selection in the language server so that documents using non-`file` URI schemes (e.g. VS Code in-memory/userdata URIs) can still be associated with a workspace worker.
related https://github.com/oxc-project/oxc-vscode/issues/25
> This PR adds support for formatting unsaved documents using the untitled:// URI scheme in the oxfmt LSP server. This enables VS Code and other LSP clients to format in-memory documents that haven't been saved to disk yet.
Angular is not supported for the moment, could not find a VS Code extension which defines a language ID for it :/
related https://github.com/oxc-project/oxc-vscode/issues/25
> This PR updates the language server formatting pipeline so that a document’s `LanguageId` (from `textDocument/didOpen`) is propagated down into tool formatting hooks, enabling formatters to make decisions even when file extensions are missing.
Boshen