universal-lsp

Zwei Projekte in einem Repository, gemeinsam gebaut, weil das eine das andere braucht:

Universal LSP – ein einziger, schneller, speicherarmer C++-Language-Server, der viele Sprachen über in Lua deklarierte Plugins abdeckt. Jede Analyse-Ebene, einschließlich der semantischen Analyse, läuft nativ in einem einzigen Prozess. Er startet nie, proxyt nie und hängt nie von rust-analyzer, pyright, clangd oder einem anderen Binär- oder Netzwerkdienst ab. Gebaut für eine terminal-zentrierte, agentengetriebene Welt: Standard-LSP über stdio für Editoren, ein MCP-Frontend für Agenten und eine headless Batch-Query-CLI für CI.

graph-lite – das fehlende SQLite für Graphen: eine kleine, abhängigkeitsfreie, einbettbare Property-Graph-Bibliothek, die jedes Projekt über einen einzigen Header einbinden kann. Ihre öffentliche Oberfläche ist eine C-ABI, sodass Ruby, JavaScript, Python, Rust, Go und C sie über ihre eigene FFI einbetten können, ohne einen Wrapper synchron halten zu müssen – dasselbe, was SQLite seine Reichweite verschafft hat. Der LSP ist ihr erster und anspruchsvollster Konsument – Call-Graphen, Import-Graphen und Symbolbeziehungen über große Codebasen hinweg, unter interaktiver Latenz – aber die API von graph-lite bleibt frei von diesem Vokabular und wird mechanisch daran gehindert, es zu lernen.

Status: Vor der Implementierung. Das Repository, die Gates, die Dokumentation und der Plan stehen; die Bauphase 1 (graph-lite-Kern) ist die aktuelle Arbeit. Nichts davon wird hier bereits ausgeliefert. Der Umfang steht in docs/spec.md; der Fortschritt in den Meilensteinen.

Warum

Heute bringt jede Sprache ihren eigenen Server mit, ihren eigenen Prozess, ihren eigenen Speicherverbrauch und ihre eigene Vorstellung davon, was „Gehe zu Definition" kostet. Öffnet man vier Projekte in vier Sprachen, laufen ein Dutzend Prozesse, die nichts teilen – keinen Cache, keinen Index, keinen Beziehungsgraphen. Und keiner von ihnen wurde für den Client entworfen, der heute den Großteil des Lesens und Bearbeitens übernimmt: ein KI-Agent, der in einem Terminal arbeitet, ohne angeschlossenen Editor, und in Schüben direkt auf der Festplatte Änderungen vornimmt.

Universal LSP ist ein Prozess für all das. Eine Sprache hinzuzufügen bedeutet, deklarative Lua-Regeln zu schreiben, nicht einen neuen Server.

Related MCP server: code-auditor-mcp

Die Ebenen

Eine Sprache bekommt exakt die Tiefe, die die Regeln ihres Plugins beschreiben – nie mehr, nie weniger, und nie abhängig davon, was auf dem Rechner installiert ist.

Ebene 4 ist das, was ein Agent tatsächlich will: was ruft das, transitiv und was bricht, wenn ich das ändere – beantwortet aus einem vorberechneten Graphen statt aus hundert Dateilesevorgängen.

Architektur

      editor  ──stdio LSP──┐
      agent   ──MCP────────┤
      CI      ──batch CLI──┘
                           │
                    ┌──────▼──────┐
                    │  shim/cli   │  thin entrypoints, no logic
                    └──────┬──────┘
                           │ unix socket
                  ┌────────▼─────────┐
                  │     daemon       │  one per user, many sessions,
                  │  engine/         │  warm caches, per-workspace state
                  └────┬────────┬────┘
              tree-sitter        │
              + Lua rules        │
                   │             │
              ┌────▼─────┐  ┌────▼─────┐
              │ analysis │──▶ graph-lite│  generic nodes + typed edges
              └──────────┘  └──────────┘  (knows nothing about code)

Abhängigkeiten fließen nur in eine Richtung: analysis → graph-lite, nie zurück. Zwei Lint-Guards und ein CI-Job für eigenständige Builds sorgen dafür, denn die Alternative – es erst beim Extrahieren zu bemerken – wäre ein Rewrite.

Schnellstart

git clone https://github.com/developerz-ai/universal-lsp.git
cd universal-lsp
bin/setup          # prerequisites → configure → link compile_commands.json
bin/check          # the full gate: format, guards, build, tests, sanitizers
bin/dev doctor     # one row per thing that can drift

Erfordert CMake ≥ 3.24, Ninja, einen C++20-Compiler, clang-format und Bun für das Repo-Tooling. bin/setup nennt alles, was fehlt, und wie man es installiert.

graph-lite allein einbetten

graph-lite wird ohne Kenntnis dieses Repositorys gebaut – das wird bei jedem PR geprüft, sodass das spätere Extrahieren ein git mv bleibt und kein Rewrite:

cmake -S graph-lite -B build/graph-lite -G Ninja
cmake --build build/graph-lite

#include "graph-lite.h"     /* the contract: C linkage, opaque handles, status codes */

#include "graph-lite.hpp"   // C++ ergonomics over the same entry points, header-only

require "ffi"               # and the same from Ruby, JS, Python, Rust, Go
module GraphLite
  extend FFI::Library
  ffi_lib "graph-lite"
  attach_function :graph_lite_version_string, [], :string
end

Eine C-Übersetzungseinheit in der Testsuite wird als C kompiliert und gelinkt, damit ein Header, der nicht mehr C-kompatibel ist, unseren Build scheitern lässt, statt deiner Integration.

API und Datenmodell: docs/graph-lite/README.md · warum C: ADR 0004.

Sprachen zum Start

TypeScript · JavaScript · Ruby · C · C++ · Lua · Python · Java · Kotlin · Swift · Rust

Die Ebenen 1 und 2 kommen zuerst über alle elf Sprachen – das ist der größte Teil des Werts für Editoren und Agenten. Die Tiefe von Ebene 3 wächst pro Sprache von dort aus und degradiert zu „unbekannter Typ", statt zu einem falschen.

Dokumentation

Mitwirken

Lies CONTRIBUTING.md, dann CLAUDE.md. Plugins für Sprachen außerhalb der offiziellen elf brauchen keine Genehmigung und keinen Platz in diesem Repo – veröffentliche ein Git-Repository und pinne es.

Lizenz

Die Engine ist Apache-2.0. graph-lite ist MIT und bewusst unabhängig versioniert: Das Einbetten eines einzelnen Headers sollte nie erfordern, über die Lizenz des Dings nachzudenken, das es zufällig hervorgebracht hat.