LSP servers

Both products ship a Language Server Protocol implementation in Rust.

ruff server

Source: crates/ruff_server/. Invoked via the ruff server subcommand.

crates/ruff_server/src/
├── main.rs / lib.rs
├── server/        # JSON-RPC routing, lifecycle, capabilities
├── session/       # workspaces, settings, document store
├── edit/          # text-document edits
├── format.rs      # format-on-save / range formatting
├── lint.rs        # diagnostics on change/save
├── fix.rs         # code actions for autofixes
├── resolve.rs     # config resolution per workspace
└── workspace.rs

ruff server was introduced in March 2024 to replace the Python-based ruff-lsp. It supports:

• Diagnostics on open / change / save (textDocument/publishDiagnostics)
• Code actions for safe and unsafe fixes
• Format on save and range formatting (textDocument/formatting, textDocument/rangeFormatting)
• noqa quick-suppressions
• Workspace-wide lint and format commands

The server is run by editor extensions:

• astral-sh/ruff-vscode for VS Code
• Built-in support in JetBrains, Zed, Helix
• Neovim via nvim-lspconfig

ty server

Source: crates/ty_server/. Invoked via the ty server subcommand.

crates/ty_server/src/
├── main.rs / lib.rs
├── server/        # request/notification handlers
├── session/       # client state, workspace
├── document/      # in-memory document model
├── capabilities.rs
├── db.rs          # ProjectDatabase wired for the language server
├── logging.rs
└── system.rs

ty's server is built on the same Salsa database as the CLI. Each text-document edit invalidates only the files that depend on the changed content; the rest of the analysis is reused.

LSP features supported by ty server (some are still preview):

• Diagnostics
• Hover with type information
• Go-to-definition / declaration
• Find references
• Renames (cross-file when safe)
• Completions (suggestions with type-aware ordering — crates/ty_completion_*)
• IDE-only signals such as inlay hints (where present)

The IDE-specific machinery lives in crates/ty_ide.

Capabilities and protocol

Both servers use tower-lsp as the JSON-RPC framework. Capabilities are advertised in capabilities.rs files; new features must be both wired up there and implemented in the corresponding server/ handlers.

Tests

Each server has unit and integration tests:

• crates/ruff_server/tests/ — request/response fixtures.
• crates/ty_server/tests/ — similar style, plus end-to-end tests that spin up a ProjectDatabase.

Logs and debugging

Set the log level when launching the server through your editor; the logs are written to a file the client picks up. For quick reproductions, run the binary directly and pipe a recorded session over stdio.

Entry points for modification

• Adding a request/notification handler: extend the corresponding server/ module and update capabilities.rs.
• Changing the document model: see document.rs / document/ in each crate.
• Wiring a new IDE feature for ty: usually means adding a #[salsa::tracked] query in ty_ide or ty_python_semantic, then hooking it up in ty_server.

See Ruff CLI server subcommand and ty CLI server subcommand for the binary entry-points that launch these.