LSP: протокол языкового сервера¶

LSP (от англ. Language Server Protocol) — открытый протокол на основе JSON-RPC, определяющий формат взаимодействия между текстовым редактором или интегрированной средой разработки (IDE) и сервером, предоставляющим функции анализа и обработки исходного кода конкретного языка программирования. Протокол был разработан компанией Microsoft в 2016 году для унификации механизмов поддержки языков в редакторе Visual Studio Code, после чего получил широкое распространение в других редакторах.

¶История

До появления LSP каждый текстовый редактор, поддерживающий автодополнение, переход к определению или проверку синтаксиса, должен был иметь собственную реализацию интеграции с каждым конкретным языком. Для поддержки N языков в M редакторах требовалось создать N×M модулей. Такая схема приводила к дублированию работы и неравномерному качеству поддержки: популярные языки имели богатые плагины, тогда как редкие оставались без инструментов.

В 2015 году команда Visual Studio Code под руководством Эриха Гаммы (одного из авторов книги «Приёмы объектно-ориентированного проектирования») начала работу над архитектурой, разделяющей редактор и языковую логику. Логика выносилась в отдельный процесс — языковой сервер, который общался с редактором по стандартизированному протоколу. В июне 2016 года спецификация LSP была представлена публично, а к концу года протокол поддержали редакторы Vim, Emacs, Atom и другие.

В 2017 году Microsoft передала спецификацию LSP в организацию JSON-RPC Working Group, а затем в сообщество Open VSX. Протокол активно развивается: по состоянию на 2024 год актуальной является версия 3.17 спецификации.

¶Архитектура и принцип работы

LSP построен на клиент-серверной модели. Клиент — это редактор или IDE, который отображает код и принимает пользовательские действия. Сервер — отдельный процесс, часто написанный на том же языке, который анализирует (например, TypeScript-сервер написан на TypeScript, Rust-анализатор — на Rust). Связь осуществляется по JSON-RPC через стандартный ввод-вывод, сокеты или именованные каналы.

Клиент отправляет серверу уведомления об изменениях в открытых файлах (textDocument/didOpen, textDocument/didChange), а также запросы, инициируемые действиями пользователя. Сервер в ответ возвращает результаты: список автодополнений, диагностические сообщения об ошибках, информацию о символе под курсором. Диагностика может отправляться сервером асинхронно — например, при сохранении файла или в фоновом режиме.

¶Основные возможности

Протокол определяет более 60 методов, объединённых в группы:

• Навигация по коду: переход к определению (textDocument/definition), поиск всех ссылок (textDocument/references), переход к реализации (textDocument/implementation).
• Автодополнение: предложение завершений (textDocument/completion), сигнатуры функций (textDocument/signatureHelp).
• Рефакторинг: переименование символов (textDocument/rename), поиск кода для извлечения (textDocument/codeAction).
• Диагностика: синтаксические и семантические ошибки, предупреждения (textDocument/publishDiagnostics).
• Прочее: наведение для получения документации (textDocument/hover), форматирование (textDocument/formatting), подсветка вхождений символа (textDocument/documentHighlight).

Дополнительные расширения протокола (LSP extensions) реализуют специфические функции: например, поддержку Call Hierarchy (иерархия вызовов) или Semantic Tokens (семантическая подсветка на основе AST).

¶Преимущества и ограничения

¶Преимущества

• Снижение трудозатрат: для добавления поддержки языка в новый редактор достаточно реализовать один клиент LSP, а не отдельные плагины для каждого языка.
• Изоляция процессов: падение языкового сервера не приводит к краху редактора; тяжёлые вычисления выполняются вне интерфейсного процесса.
• Единообразие: пользователи получают одинаковый набор функций независимо от выбранного редактора.
• Языковая независимость: сервер может быть написан на любом языке, способном взаимодействовать по JSON-RPC.

¶Ограничения

• Накладные расходы: сериализация JSON и межпроцессное взаимодействие добавляют задержку по сравнению с встроенной реализацией.
• Сложность отладки: распределённая архитектура усложняет диагностику проблем.
• Не все функции покрыты: специфические возможности отдельных языков (например, интеграция с отладчиком или системой сборки) требуют дополнительных расширений или остаются вне протокола.

¶Реализации и применение

LSP поддерживается большинством современных редакторов: Visual Studio Code, Neovim (через встроенный клиент), Vim (через плагины), Emacs (через lsp-mode), Sublime Text, Kakoune, Helix, Zed и другие. JetBrains IDE используют собственную архитектуру, но поддерживают LSP через плагины для сторонних языков.

Известные языковые серверы:

• clangd — для C, C++ и Objective-C, на основе LLVM.
• rust-analyzer — для Rust, разрабатывается при поддержке проекта Rust.
• Pyright — для Python от Microsoft, написан на TypeScript.
• tsserver — для JavaScript и TypeScript, используется в VS Code.
• gopls — официальный сервер для Go.
• jdtls — для Java на базе Eclipse JDT.
• texlab — для LaTeX.

Протокол также применяется вне традиционных редакторов: например, в системах удалённой разработки (VS Code Remote Development) и в веб-интерфейсах (GitHub Codespaces, Gitpod).

¶Влияние на экосистему разработки

LSP стал одним из факторов, способствовавших росту популярности лёгких редакторов в конце 2010-х годов. Возможность получить полноценную языковую поддержку в Neovim или Vim без установки громоздких плагинов привела к миграции части разработчиков с традиционных IDE. Протокол также повлиял на стандартизацию инструментов: новые языки (например, Zig, Gleam) часто разрабатывают LSP-сервер как обязательную часть официального инструментария.

В 2021 году на основе идей LSP появился протокол Debug Adapter Protocol (DAP), стандартизирующий взаимодействие редакторов с отладчиками.

¶Связанные технологии

LSP часто рассматривают вместе с другими протоколами из экосистемы Microsoft: Language Server Index Format (LSIF) — для хранения индексов кода; Debug Adapter Protocol (DAP); TextMate-грамматиками для подсветки синтаксиса. Вместе они образуют основу современной модульной архитектуры редакторов кода.