Sorbet: graduelle Typprüfung für große Ruby-Codebasen

Typen ohne neue Ruby-Sprache

Sorbet ist ein schneller Typchecker für Ruby. Sein Ansatz bleibt bei vorhandener Ruby-Syntax, damit Editoren und bestehende Werkzeuge weiterverwendet werden können. Annotationen machen Erwartungen sichtbar und sollen Leser ebenso unterstützen wie Autoren. Die Einführung ist graduell gedacht: Ein großes Repository muss nicht an einem Tag vollständig typisiert werden. Das ist für gewachsene Anwendungen wichtiger als ein theoretisch umfassendes Typsystem, weil Teams unterschiedliche Teile des Codes zu unterschiedlichen Zeitpunkten bearbeiten können. Das Repository beschreibt Sorbet als Werkzeug, das Fehler und Vorschläge schnell zurückgeben soll.

Explizit, aber mit begrenzter Komplexität

Die dokumentierten Nutzerprinzipien setzen auf explizite Angaben, ohne unnötige Ausführlichkeit zu verlangen. Mehr Text soll durch mehr Sicherheit gerechtfertigt sein, Fehlermeldungen sollen verständlich bleiben. Sorbet will so einfach wie möglich und zugleich stark genug für realen Ruby-Code sein. Die Kompatibilität mit Ruby ist deshalb kein Nebendetail: Bestehende Syntax bewahrt den Anschluss an Editoren und erleichtert die Verbesserung älterer Systeme. Skalierung meint dabei Laufzeit, Zahl der Mitarbeitenden, Codezeilen und das Alter der Codebasis.

Der dokumentierte lokale Einstieg

Die Contributor-README nennt brew install bazel autoconf coreutils parallel als Abhängigkeiten. Nach git clone https://github.com/sorbet/sorbet und cd sorbet baut ./bazel build //main:sorbet --config=dbg das Programm. Der schnelle Funktionstest lautet bazel-bin/main/sorbet -e "42 + 'hello'". Diese Befehle beziehen sich auf den Entwicklungsstand des Repositorys und bauen Sorbet aus den Quellen. Wer nur den Checker einsetzen möchte, sollte die öffentlichen Dokumente auf sorbet.org heranziehen; die vorliegende README richtet sich ausdrücklich auch an Mitwirkende.

Internals und Schnittstellen für Entwickler

docs/internals.md beschreibt die inneren Abläufe und ist mit der Contributor-README verknüpft. Dazu kommt ein Vortrag über die Architektur und die Gründe für die Geschwindigkeit. Das Repository behandelt nicht nur den Checker selbst, sondern auch Editorfunktionen und inkrementelle Arbeitsweisen. Die Testübersicht umfasst test_corpus-Tests, Expectation-Tests, CLI-Tests, LSP-Tests und aufgezeichnete LSP-Szenarien. Damit wird sichtbar, dass ein Fehler in einer Diagnose oder einer Editoraktion als Verhalten des Systems betrachtet wird, nicht nur als Buildproblem.

Testkorpus statt bloßer Build-Erfolg

Für Änderungen stehen im README konkrete Testbereiche: Definitionen finden, Referenzen suchen, Typdefinitionen öffnen, Hover, Completion, Workspace-Symbole, Implementierungen, Umbenennung von Konstanten und inkrementelle Typprüfung. Ein erfolgreicher Bazel-Build sagt daher nur, dass das Programm erzeugt wurde. Bei einer Änderung am Resolver oder an LSP-Funktionen sollten die zugehörigen Tests und Erwartungsdateien geprüft werden. Diese Struktur macht Sorbet für große Ruby-Repositories interessant, erhöht aber den Aufwand für Entwickler, die C++, Bazel und Ruby-Diagnosen gemeinsam verstehen müssen.

Praxisprüfung für sorbet

Die Entwicklungsperspektive ist für Sorbet besonders aufschlussreich. Das Repository enthält Hinweise zu Debugging, Dokumentation, Editor- und Umgebungssetup sowie Bazel. Änderungen werden dadurch nicht nur an der ausführbaren Datei bewertet, sondern an der Erfahrung im Ruby-Editor. LSP-Tests prüfen beispielsweise Hover und Completion, während Erwartungstests Diagnosen festhalten. Bei einer schrittweisen Einführung kann ein Team zunächst einzelne Ruby-Dateien annotieren und die Reaktion des Checkers beobachten. Die README macht klar, dass Sorbet für große, alte und von vielen Personen bearbeitete Codebasen skalieren soll. Diese Zielsetzung bedeutet trotzdem Pflegeaufwand: Annotationen müssen zu Ruby-Code und Projektkonventionen passen, und eine neue Sorbet-Version kann Diagnosen ändern. docs/internals.md ist daher die passende Quelle, wenn nicht nur die Meldung, sondern die Architektur hinter ihr untersucht werden soll. Ein Ergebnis sollte dabei immer mit dem konkreten Projektartefakt abgeglichen werden. Bei diesem Artikel sind das die genannte README, die dokumentierten Befehle und die erzeugte Ausgabe. Dieser Abgleich trennt eine belegte Funktion von einer plausiblen Annahme. Für den Betrieb ist außerdem ein kleiner Rückweg nötig: Testdaten, eine isolierte Umgebung und die Möglichkeit, die Änderung oder den Lauf zu entfernen. So bleibt die Prüfung auf den beschriebenen Anwendungsfall begrenzt. Die Quellen sind als Einstieg verknüpft, während die Details der installierten Version maßgeblich bleiben. Ein kurzer Probelauf mit sichtbarer Ausgabe liefert dafür die relevanteste Information und zeigt zugleich, welche Teile des Projekts im eigenen Umfeld fehlen oder anders reagieren.

Redaktionelles Fazit

Sorbet passt zu Ruby-Teams, die Typgrenzen schrittweise in eine bestehende Codebasis einführen wollen und Bazel sowie C++-Buildwerkzeuge betreiben können. Vor einer breiten Einführung sollte ./bazel build //main:sorbet --config=dbg gelingen und bazel-bin/main/sorbet -e "42 + 'hello'" die erwartete Diagnose liefern.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes