fallow — was ein Codebase-Analyzer für unsere App-Entwicklung leistet

Ein Linter prüft einzelne Dateien. Der TypeScript-Compiler prüft Typen. Was beide nicht beantworten, ist die Frage über das ganze Projekt hinweg: Welcher Code wird eigentlich nirgends mehr benutzt? Welche Abhängigkeit steht im package.json, ohne dass sie noch jemand importiert? Wo verweisen Module im Kreis? Genau diese Lücke schließt fallow — eine in Rust geschriebene Engine, die eine TypeScript-/JavaScript-Codebasis als zusammenhängenden Graphen liest statt als Haufen Einzeldateien.

Der technische Kniff ist Geschwindigkeit ohne Genauigkeitsverlust: fallow nutzt den Oxc-Parser nativ in Rust und verteilt die Arbeit über alle Prozessorkerne. Das Ergebnis sind Analysen im Sekundenbruchteil — in veröffentlichten Benchmarks 26- bis 34-mal schneller als das verbreitete knip, bei der Duplikat-Suche um ein Vielfaches schneller als jscpd. Selbst ein Projekt in der Größe von Next.js mit über zwanzigtausend Dateien ist in rund anderthalb Sekunden durch. Wichtig für uns: Es braucht dafür weder den TypeScript-Compiler noch eine laufende Node-Umgebung, und es steckt keine KI im Analysekern — jeder Befund ist deterministisch und über den Graphen belegbar.

Was fallow konkret findet, deckt sich auffällig genau mit unseren wiederkehrenden Baustellen. Es meldet ungenutzte Dateien, Exporte, Typen und Abhängigkeiten; es erkennt Code-Duplikate in vier Schärfegraden bis hin zu bloß umbenannten Variablen; es findet zirkuläre Abhängigkeiten auch über Paket-Grenzen hinweg in einem Monorepo; und es kann Architektur-Regeln zwischen Schichten durchsetzen. Über hundert mitgelieferte Plugins erkennen die Einstiegspunkte gängiger Frameworks automatisch — darunter SvelteKit, Astro, Vite, Drizzle, Vitest und pnpm-Workspaces samt Catalog. Das ist, fast eins zu eins, unser Stack.

Der Hebel liegt für uns bei den geteilten @mana/-Paketen. shared-ui, themes, shared-auth-sso und die anderen werden quer durchs Ökosystem konsumiert, und wir sind schon mehrfach darüber gestolpert, dass sich ein 0.x-Paket unbemerkt weiterbewegte und still Konsumenten brach. fallow zeigt, welche Exporte niemand mehr nutzt und welche Re-Export-Ketten ins Leere laufen, bevor daraus ein Problem wird. Und weil wir regelmäßig ganze Module zurückbauen — fünf Module sind aus managarten herausgelöst worden, das Bibliotheks-Modul wurde zu Kollekta, der Pageta-Feed ruht — ist ein Werkzeug, das vor dem Löschen belegt, was wirklich tot ist, bares Risiko gespart. fallow löscht dabei bewusst nichts von selbst: Das Entfernen einer Datei, heißt es in der Projektdokumentation, sei eine Entscheidung, die man selbst treffen solle.

Das Lizenzmodell ist zweistufig, und die Unterscheidung ist entscheidend. Der gesamte statische Kern — Dead Code, Duplikate, Zyklen, Architektur, das PR-Risiko-Gate — steht unter MIT-Lizenz und ist kostenlos. Geld kostet nur eine optionale Laufzeit-Schicht, die echte Produktions-Coverage hinzuzieht, um zu beantworten, was im Betrieb tatsächlich ausgeführt wurde. Diese Schicht ist proprietär — und wir brauchen sie nach erster Einschätzung nicht. Genau hier gilt die Disziplin: Wir würden ausschließlich die quelloffene CLI als Entwickler-Abhängigkeit halten und keine Bindung an eine fremde Cloud aufbauen. Ein junges Projekt eines einzelnen Anbieters ist ein Risiko, das man durch genau diese Begrenzung klein hält.

Der Praxistest: vierzehn eigene Apps

Wir haben es nicht bei der Theorie belassen, sondern fallow auf unseren eigenen Code losgelassen — auf die Reader-App Pageta, auf die Aufnahme-App Memoro und auf zwölf weitere, noch nicht veröffentlichte Apps. Das Tempo aus den Benchmarks bestätigt sich: Memoro mit fast sechstausend Dateien war in unter einer Sekunde analysiert, die kleineren Apps in Sekundenbruchteilen. Alle Apps bekamen einen Wartbarkeits-Wert zwischen 92 und 94 von 100 — solide. Soweit die gute Nachricht.

Die lehrreiche Nachricht steckt im Detail, und sie ist der eigentliche Grund für diesen Nachtrag. Bei den Duplikaten und den Abhängigkeits-Kreisen traf fallow ins Schwarze. In Pageta zeigte es, dass zwei Server-Routen denselben Aufruf an unseren Sprachmodell-Dienst Wort für Wort doppelt führten — wir haben das in eine gemeinsame Funktion zusammengezogen. In Memoro fand es zwei echte Importkreise im Server, bei denen sich zwei Module gegenseitig brauchten; wir haben die gemeinsame Funktion in ein eigenes kleines Modul gelöst und die Kreise damit sauber aufgetrennt. Beides sind Funde, die ein normaler Compiler nicht meldet, weil sie erst über das ganze Projekt hinweg sichtbar werden — genau das Versprechen des Werkzeugs, eingelöst.

Beim Punkt „ungenutzte Abhängigkeit“ dagegen war Vorsicht das Gebot. fallow meldete in Pageta fünf überflüssige Pakete. Wir haben jedes einzeln geprüft — und nur eines war wirklich tot. Die anderen vier waren Fehlalarme, jeder aus einem anderen Grund: Zwei werden von unserem geteilten UI-Paket als sogenannte Peer-Abhängigkeit vorausgesetzt und müssen deshalb dastehen. Eines wird nicht im Code importiert, sondern über ein Build-Plugin für die Web-App-Installierbarkeit indirekt geladen. Und eines wird gar nicht importiert, sondern von einem Hilfsskript aufgerufen — was der Analyzer, der nur Importe verfolgt, nicht sehen kann. In der Mobil-App von Memoro wiederholte sich das Muster verschärft: Dort war fast jede gemeldete „ungenutzte“ Abhängigkeit in Wahrheit ein Konfigurations-Paket des Mobil-Frameworks Expo, das über Umwege geladen wird.

Dasselbe gilt für zwei weitere Meldungs-Arten. „Unauflösbarer Import“ traf bei uns fast immer CSS-Dateien oder interne Kurz-Schreibweisen für Pfade, die der Analyzer nicht kennt — die Dateien existieren alle. Und „ungenutzte Datei“ zeigte in einer unserer Apps auf Spiel-Daten, die zur Laufzeit dynamisch geladen werden, sowie auf eine Server-Route, die das Werkzeug nicht als Einstiegspunkt erkannte. Hätten wir diesen Meldungen blind gefolgt, hätten wir funktionierende App-Teile gelöscht. Die wichtigste Lehre des Tests ist deshalb eine über die Arbeitsweise: Ein Treffer von fallow ist ein Verdacht, kein Urteil. Bei einem jungen Verein, der wenig Zeit hat, ist es ein gutes Werkzeug genau dann, wenn man seine Funde noch von Hand gegenprüft, statt ihnen zu vertrauen.

Fazit

fallow bleibt empfehlenswert — als quelloffener, lokaler Helfer, nicht als Autorität. Seine Stärke sind die Funde, die über das ganze Projekt hinweg sichtbar werden: Duplikate und Importkreise, die ein Compiler übersieht. Diese Funde haben uns in zwei Apps bereits zu echten Verbesserungen geführt. Seine Schwäche ist die Abhängigkeits- und Datei-Prüfung, die in einem Stack wie unserem — viele geteilte Pakete, ein Mobil-Framework mit Eigenheiten — zu viele Fehlalarme erzeugt, um ihr blind zu folgen.

Die praktische Konsequenz: Wir nutzen die kostenlose CLI lokal und perspektivisch als unverbindlichen Bericht in der Baupipeline, niemals als hartes Tor, das einen Build blockiert. Vor einer festen Einbindung pflegen wir eine Ausnahme-Liste für die bekannten Fehlalarm-Muster. Die bezahlte Cloud-Schicht brauchen wir weiterhin nicht, und an einen einzelnen Anbieter binden wir uns nicht. Es bleibt, was hier öfter gilt: ausprobieren, prüfen, und nur das übernehmen, was sich bewährt.