LSP integration

Both Ruff and ty ship native Rust language servers. This page describes the surface area users get and how the two servers relate.

Two servers

Binary	Crate	Started by	Audience
ruff server	crates/ruff_server	The ruff server subcommand	Editors that want lint + format
ty server	crates/ty_server	The ty server subcommand	Editors that want type checking

Editors typically run both. The Ruff team's astral-sh/ruff-vscode extension manages ruff server; ty's official VS Code extension manages ty server. Other editors (Neovim, Helix, Zed, JetBrains) configure them via standard LSP machinery.

What ruff server provides

• Diagnostics on open / change / save.
• Code actions:
  • Apply safe fix on the line.
  • Apply unsafe fix (clearly labeled).
  • Fix all in file.
  • Add # noqa: <code> to suppress.
  • Format file (or selection).
  • Organize imports (isort-equivalent).
• Format on save.
• Workspace commands: ruff: lint, ruff: format, ruff: organize imports.
• Configuration via workspace/configuration (per-folder settings).

ruff server is one-shot per request: it parses the file and runs the linter from scratch each time. This keeps it simple and matches CLI semantics.

What ty server provides

• Diagnostics with type errors.
• Hover with inferred types.
• Go-to definition / declaration / type definition.
• Find references.
• Rename (single-file and cross-file when unambiguous).
• Completion (type-aware ordering, string-literal-aware where applicable).
• Inlay hints (subset).
• Document symbols.

ty server is Salsa-backed. It keeps the database alive across edits, invalidates only the inputs that change, and recomputes the minimum needed.

Sharing infrastructure

Both servers:

• Speak LSP via tower-lsp.
• Use ruff_db::System to abstract the file system (preferring open buffers over disk content).
• Reuse the diagnostic types from ruff_diagnostics.
• Share configuration loading patterns (Ruff via ruff_workspace, ty via ty_project).

But they don't share state — each server has its own session and document store.

Configuration

Editors typically forward settings via workspace/configuration. Common keys:

• ruff.lint, ruff.format, ruff.organizeImports (booleans gating each capability)
• ruff.path (override binary path, used by some clients)
• ruff.lint.preview, ruff.format.preview (preview-mode toggles)
• ty.disableLanguageServices (ty)
• ty.completion.* (completion tuning)

Concrete client documentation is on https://docs.astral.sh/ruff/editors/.

Logging

Both servers respect RUST_LOG and write to a log file the client picks up. For remote/sandboxed setups, increasing the log level is the first triage step when something looks wrong.

Tests

Each server has unit tests for handlers and integration tests that drive the JSON-RPC protocol end-to-end. Both crates are exercised by their parent CLI binaries' integration tests too (cargo run -p ruff server / cargo run --bin ty server).

See also

• crates/ruff_server for the Ruff LSP internals.
• crates/ty_server for the ty LSP internals.
• apps/lsp-servers for a deployment-oriented view.