React v19 - ESLint-Regeln

React v19+ — ESLint-Regeln

0:00 Ein Linter hat den undankbarsten Job im Werkzeugkasten: Er meldet sich immer dann, wenn man eigentlich fertig sein wollte. Entsprechend ist sein Ruf — für viele ist er der Kollege, der über Anführungszeichen diskutiert. Genau darum geht es heute nicht. Die interessanten React-Regeln prüfen keinen Geschmack, sondern Korrektheit: ob ein Hook an einer Stelle stehen darf, wo er steht, ob eine Komponente Nebenwirkungen hat, die sie nicht haben dürfte.

0:25 Das sind Fehler, die sich sonst als sporadisches Fehlverhalten zeigen — und die zu finden Stunden kostet. Der Linter findet sie in Millisekunden.

React-Linting mit ESLint

0:34 Der rote Faden führt von der Konfigurationsdatei bis zum team-weiten Regelwerk, das in der Bauleitung geprüft wird. Zwischendurch klären wir, welche Regeln echte Fehler fangen und welche nur Meinung sind — eine Unterscheidung, die im Alltag über den Frieden im Team entscheidet. Und wir schauen uns an, was neu dazugekommen ist: Der React Compiler hat Diagnosen mitgebracht, die man auch dann nutzen kann, wenn man den Compiler selbst gar nicht einsetzt.

1:00 Die mittlere Frage ist die eigentlich interessante. Fast jedes Team hat schon einmal eine hitzige Diskussion über die Abhängigkeitslisten von Effekten geführt — und erstaunlich oft endet sie damit, dass jemand die Regel per Kommentar ausschaltet. Wir werden heute sehen, warum das fast immer die falsche Antwort ist und was die Regel einem eigentlich sagen will.

1:19 Und sagen Sie ruhig, ob Sie noch mit der alten Konfigurationsform arbeiten. Falls ja, ist der erste Teil des Tages für Sie unmittelbar praktisch.

Grundlagen & Setup

1:28 Fangen wir bei der Grundlage an. ESLint hat sein Konfigurationsformat gewechselt, und das ist kein sanfter Übergang, sondern ein Schnitt. Klären wir also, wie eine zeitgemäße Einrichtung aussieht und welche Bausteine ein React- Projekt heute braucht. Wer noch mit der alten Form arbeitet, bekommt hier gleich die Migrationsanleitung mitgeliefert.

1:49 Der wichtige Gedanke steckt im ersten Satz: React hat Regeln, die nicht im Code selbst stehen. Eine Komponente muss bei gleichen Eingaben gleich aussehen; Hooks müssen immer in derselben Reihenfolge aufgerufen werden. Der Compiler kann das nicht erzwingen, die Sprache weiß nichts davon — es sind Abmachungen. Ein Programm, das sie bricht, lässt sich problemlos übersetzen und startet auch.

2:12 Es verhält sich nur gelegentlich falsch. Der Linter ist die einzige Instanz, die diese Abmachungen prüft. Das ist ein grundsätzlich anderer Auftrag als "Semikolon vergessen". Der erste Punkt ist keine Empfehlung, sondern eine Tatsache: Ab Version neun gibt es das alte Format nicht mehr. Wer noch damit arbeitet, hat eine anstehende Migration, keine Wahlmöglichkeit. Interessanter ist der dritte Punkt.

2:36 Die automatische Versionserkennung klingt nach Kleinkram, entscheidet aber darüber, ob Sie sinnvolle oder unsinnige Warnungen bekommen — manche Regeln gelten nur für ältere React-Stände. Und der letzte Punkt nennt eine Alternative, die wir uns am Ende genauer ansehen: ein neueres Plugin, das Typinformationen mitnutzt. Fünf Schritte, die zusammen etwa fünfzehn Zeilen ergeben. Der dritte verdient eine Erklärung, weil er sonst als überflüssig erscheint.

3:03 Bis React 16 musste man React in jeder Datei importieren, sonst funktionierte die JSX-Syntax nicht. Seither ist das nicht mehr nötig — aber die entsprechenden Regeln gibt es noch, und ohne diesen einen Schritt beschwert sich der Linter über einen fehlenden Import, den Sie zu Recht weggelassen haben. Es ist die häufigste Irritation beim Einrichten.

3:24 Was Sie hier sehen, ist die ganze Idee des neuen Formats: Die Konfiguration ist ein Feld von Blöcken, die von oben nach unten angewendet werden. Spätere Blöcke überschreiben frühere — das war früher ein undurchsichtiges Vererbungssystem und ist jetzt schlicht eine Reihenfolge. Der zweite Eintrag ist der Schalter aus dem letzten Punkt, der die überholten Import-Regeln abstellt.

3:45 Und die Versionserkennung ganz unten sorgt dafür, dass Sie nur Regeln bekommen, die zu Ihrem React-Stand passen. Mehr braucht ein Grundgerüst nicht. Setzen Sie das jetzt selbst auf. Der Prüfstein ist bewusst schlicht: Der Lint-Lauf soll durchlaufen und dabei tatsächlich etwas prüfen. Machen Sie unbedingt die Gegenprobe — bauen Sie absichtlich einen Fehler ein und schauen Sie, ob er gemeldet wird.

4:09 Eine Konfiguration, die nichts findet, weil sie gar nicht greift, sieht von außen genauso aus wie sauberer Code. Wer eine alte Konfiguration mitbringt, nimmt die Zusatzaufgabe und migriert sie. Das ist die Übung mit dem unmittelbarsten Nutzen. Der letzte Punkt ist der unangenehmste, weil das Ergebnis so schwer zu deuten ist.

4:28 Wenn beide Konfigurationsformen im Projekt liegen, gewinnt je nach Version und Aufrufweg mal die eine, mal die andere — und Sie erleben, dass der Linter lokal etwas anderes meldet als in der Bauleitung. Alte Datei löschen, nicht liegen lassen. Der zweite Punkt ist die Irritation mit dem Import, über die wir gesprochen haben, und der dritte führt zu Regeln, die für Ihren React-Stand gar nicht gelten.

Die Recommended-Regeln im Detail

4:51 Schauen wir uns jetzt an, was das empfohlene Regelwerk eigentlich prüft. Der Untertitel des Kapitels ist Programm: Es geht um Korrektheit, nicht um Stil. Und es geht um die Frage, welche dieser Regeln in einem TypeScript-Projekt schlicht überflüssig geworden sind. Diese Unterscheidung entscheidet übrigens darüber, ob Meldungen im Team ernst genommen werden oder im Rauschen untergehen.

5:13 Nehmen wir die bekannteste Regel als Beispiel, weil sie so gut zeigt, worum es geht. React braucht bei Listen einen stabilen Schlüssel je Eintrag, um zu erkennen, welches Element welches ist. Fehlt er, funktioniert alles — bis sich die Liste ändert. Dann rutschen plötzlich Eingaben in die falsche Zeile oder Animationen laufen am falschen Element.

5:34 Das ist ein Fehler, der beim Entwickeln nie auffällt und im Betrieb sporadisch zuschlägt. Genau solche Fälle deckt das empfohlene Regelwerk ab. Die Prüfungen für Prop-Typen sind dagegen ein Relikt aus der Zeit vor TypeScript. Der letzte Punkt ist wichtiger, als er klingt, denn er entscheidet über die Akzeptanz im Team. Wenn ein Linter in einem TypeScript-Projekt lauter Meldungen über fehlende Prop-Typen ausspuckt, sind das hundert Warnungen, die alle falsch sind — die Typen stehen ja da.

6:02 Und was passiert dann? Man gewöhnt sich daran, Warnungen zu überfliegen. Damit ist das Werkzeug wertlos geworden, weil die echten Fehler im Rauschen untergehen. Ein Linter ist nur so nützlich, wie seine Meldungen ernst genommen werden. Die Faustregel im letzten Punkt ist die eigentliche Botschaft dieses Kapitels: das empfohlene Regelwerk als Basis nehmen und gezielt einzelne Regeln abschalten — statt sich sein eigenes Set von Grund auf zusammenzustellen.

6:28 Der Vorteil liegt in der Zukunft: Kommt eine neue Regel dazu, weil sich ein neues Fehlermuster gezeigt hat, bekommen Sie sie automatisch. Wer alles einzeln aufzählt, bleibt auf dem Stand des Tages stehen, an dem er die Datei geschrieben hat. Drei Zeilen, die das Prinzip zeigen. Die ersten beiden schalten ab, was TypeScript besser kann — Typen sind Prop-Typen, nur eben zur Übersetzungszeit geprüft.

6:52 Die dritte Zeile ist bewusst dagegengesetzt: Der Listenschlüssel bleibt nicht nur an, er wird ausdrücklich zum Fehler hochgestuft. Das ist die Unterscheidung, um die es in diesem Kapitel geht. Manche Meldungen sind Rauschen und gehören weg. Andere sind echte Fehler und sollten den Bau anhalten. Beides gehört in dieselbe Datei, mit klarer Absicht.

7:13 Jetzt geht es ans Aufräumen. Sie bekommen ein Projekt mit den typischen Fehlern und arbeiten die Meldungen ab. Achten Sie dabei auf einen Punkt, der leicht verlorengeht: Verstehen Sie bei jeder Meldung, was schiefgehen könnte, statt nur den Vorschlag zu übernehmen. Beim Listenschlüssel etwa lohnt es sich, den Fehler einmal live zu erleben — Liste umsortieren, Eingabefeld beobachten.

7:34 Danach vergisst man diese Regel nicht mehr, und man diskutiert auch nicht mehr darüber, ob sie eine Warnung oder ein Fehler sein sollte. Der zweite Punkt ist der, den ich am häufigsten sehe: Eine Regel meldet etwas Unbequemes, also stuft man sie herab — aus Fehler wird Warnung, aus Warnung wird nichts. Das Problem verschwindet damit aus der Anzeige, aber nicht aus dem Code.

7:56 Wenn eine Regel stört, gibt es zwei ehrliche Antworten: Entweder man behebt, was sie meldet, oder man entscheidet begründet, dass sie im eigenen Kontext nicht passt, und schaltet sie ganz ab. Die Grauzone dazwischen ist der Ort, an dem Regelwerke verrotten.

Best-Practice- & Stil-Regeln

8:11 Jenseits des empfohlenen Sets wird es interessanter — und diskussionsanfälliger. Hier geht es um Regeln, die nicht offensichtlich falschen Code melden, sondern Muster, die später Probleme machen. Und um eine Grenze, die man sauber ziehen sollte: Formatierung gehört nicht in den Linter. Genau bei diesen Regeln entstehen die längsten Diskussionen — und deshalb ist die Begründung wichtiger als die Entscheidung.

8:35 Die genannten Regeln haben einen gemeinsamen Nenner, den man kennen sollte: Sie alle warnen vor Dingen, die bei jedem Neuzeichnen neu entstehen. Eine Komponente, die innerhalb einer anderen definiert wird, ist bei jedem Durchlauf eine andere Komponente — React wirft dann den gesamten Teilbaum weg und baut ihn neu auf, samt Zustand.

8:54 Ein Kontextwert, der jedes Mal frisch zusammengesetzt wird, benachrichtigt alle Verbraucher, auch wenn sich nichts geändert hat. Diese Fehler sind unsichtbar, bis die Anwendung plötzlich zäh wird oder Eingaben verloren gehen. Der letzte Punkt ist eine Arbeitsteilung, die man einmal richtig ziehen sollte. Formatierung — Einrückung, Zeilenumbrüche, Anführungszeichen — gehört zu einem Formatierer, der sie beim Speichern einfach herstellt. Der Linter soll sich um Bedeutung kümmern.

9:22 Wer beides vermischt, bekommt zwei Werkzeuge, die gegeneinander arbeiten: Der eine formatiert, der andere beschwert sich, und im Zweifel schaltet jemand entnervt eines von beiden ab. Diese Trennung ist keine Geschmacksfrage, sie erspart eine ganze Klasse von Ärger. Der fünfte Punkt ist der wichtigste des Kapitels und wird am häufigsten übersprungen: Jede Entscheidung braucht eine Begründung.

9:45 Nicht in einem Dokument, das niemand liest, sondern als Kommentar direkt neben der Regel. Der Grund ist praktisch: In einem Jahr kommt jemand Neues ins Team, stolpert über eine unbequeme Regel und fragt, warum. Steht die Antwort daneben, ist die Diskussion in dreißig Sekunden erledigt. Steht sie nicht da, wird die Regel abgeschaltet — und der Fehler, den sie verhindern sollte, kommt zurück.

10:09 Die mittlere Regel verdient eine Erklärung, weil das dahinterliegende Risiko wenig bekannt ist. Wenn Sie einen Link in einem neuen Tab öffnen, bekommt die Zielseite in älteren Browsern einen Zugriff auf Ihre Seite — und kann sie im Hintergrund durch eine gefälschte Anmeldeseite ersetzen. Der Nutzer wechselt zurück, sieht das vertraute Aussehen und tippt seine Zugangsdaten ein. Die Gegenmaßnahme ist ein einziges Attribut.

10:32 Deshalb steht diese Regel hier auf Fehler, nicht auf Warnung — sie kostet nichts und verhindert etwas, das man sonst nie bemerkt. Diese Übung ist Teamarbeit, kein Tippen. Stellen Sie ein Regelwerk zusammen und schreiben Sie zu jeder Entscheidung einen Halbsatz. Sie werden schnell merken, wo es wirklich strittig ist — meist bei den Regeln zu Funktionen im Markup und zum Weiterreichen von Eigenschaften.

10:54 Genau dort ist die Begründung wertvoller als die Entscheidung selbst. Und wo Sie sich nicht einig werden: Setzen Sie die Regel auf Warnung, notieren Sie den offenen Punkt und entscheiden Sie in vier Wochen mit Erfahrung statt mit Meinung. Der letzte Punkt ist die Zusammenfassung dieses Kapitels: Ein Regelwerk ohne Begründungen führt zu Streit in der Code-Durchsicht.

11:15 Statt über die Sache zu reden, redet man über die Regel — und der Linter, der eigentlich Diskussionen beenden sollte, erzeugt neue. Der dritte Punkt ist ebenfalls typisch: Sicherheitsregeln als bloße Warnung einzustufen bedeutet in der Praxis, dass sie in einer Liste von zweihundert Warnungen untergehen. Was sicherheitsrelevant ist, gehört auf Fehler. Alles andere ist eine höfliche Empfehlung an niemanden.

Hooks & React Compiler

11:39 Jetzt kommen wir zu dem Teil, der die meiste Zeit spart und die meisten Diskussionen auslöst. Die Hook-Regeln sind nicht verhandelbar — sie prüfen etwas, das React zwingend voraussetzt. Und es ist etwas Neues dazugekommen: Diagnosen aus dem React Compiler, die auch ohne ihn nutzbar sind. Wir klären dabei auch, warum der beliebteste Ausweg aus einer Hook-Warnung fast immer der falsche ist.

12:02 Warum die Hook-Regeln so streng sind, versteht man mit einem Bild. React merkt sich die Zustände einer Komponente nicht unter Namen, sondern in der Reihenfolge ihres Aufrufs — wie nummerierte Schließfächer. Steht ein Hook in einer Bedingung, verschiebt sich beim nächsten Durchlauf die ganze Nummerierung: Was in Fach zwei lag, wird jetzt aus Fach eins gelesen.

12:22 Das Ergebnis sind Werte, die scheinbar grundlos in andere Variablen wandern. Genau deshalb ist das keine Stilregel, sondern die Bedingung dafür, dass Hooks überhaupt funktionieren. Der dritte Punkt ist die eigentliche Neuigkeit. Der React Compiler muss, um Optimierungen sicher vornehmen zu können, sehr genau prüfen, ob Ihr Code sich berechenbar verhält.

12:43 Diese Analyse ist jetzt als Lint-Regel verfügbar — auch wenn Sie den Compiler gar nicht einsetzen. Sie bekommen also die Prüfung ohne die Umstellung. Und ganz nebenbei ist das die beste Vorbereitung auf eine spätere Einführung: Wenn diese Regeln heute grün sind, ist der Schritt später eine Konfigurationszeile statt eines Projekts.

13:03 Der dritte Schritt wird oft übersehen und ist bei eigenen Hooks entscheidend. Der Linter kennt die eingebauten Hooks und weiß, dass deren zweites Argument eine Abhängigkeitsliste ist. Ihre selbstgeschriebenen Hooks kennt er nicht — dort prüft er schweigend gar nichts. Ein Eintrag in der Konfiguration ändert das. Der letzte Punkt ist ein Rat zur Gelassenheit: Die neuen Compiler-Diagnosen finden in gewachsenem Code erfahrungsgemäß viel.

13:11 Lesen Sie das erst einmal als Bestandsauf- nahme, bevor Sie anfangen, alles umzubauen. Kurz und aussagekräftig. Oben die empfohlene Sammlung, die die beiden Pflichtregeln bringt, darunter eine einzelne Compiler-Diagnose — bewusst als Warnung, nicht als Fehler. Diese Diagnose meldet ein sehr verbreitetes Muster: einen Zustand innerhalb eines Effekts zu setzen.

13:30 Das ist nicht immer falsch, aber sehr oft ein Zeichen dafür, dass ein Wert berechnet statt gespeichert werden sollte. Es als Warnung zu starten ist die richtige Dosierung — Sie sehen die Stellen, ohne dass der Bau stehenbleibt. Hier bekommen Sie eine Komponente, die reichlich Effekte einsetzt, und bringen die Regeln zum Schweigen — durch Umbau, nicht durch Abschalten. Das ist der Kern der Übung.

13:53 Der wichtigste Satz steht im Erfolgskriterium: Das Verhalten soll korrekt bleiben. Prüfen Sie das tatsächlich, denn eine vollständige Abhängigkeitsliste kann durchaus zu einer Endlosschleife führen. Wenn das passiert, ist das kein Argument gegen die Regel — es ist der Hinweis, dass die Struktur des Effekts nicht stimmt. Der erste Punkt ist die wichtigste Botschaft des ganzen Kapitels.

14:16 Der Ignore-Kommentar über einer Abhängigkeitsliste ist in echten Projekten allgegenwärtig, und fast immer verbirgt er ein echtes Problem. Die Regel sagt nämlich nicht "hier fehlt ein Eintrag" — sie sagt "dieser Effekt hängt von etwas ab, das er nicht beobachtet". Wenn das Hinzufügen zu einer Schleife führt, ist die Antwort ein anderer Zuschnitt des Effekts, nicht ein Kommentar.

14:38 Der Kommentar ist eine Notiz an das Team, dass hier ein bekannter Fehler wohnt.

Ausblick, Migration & Team-Rollout

14:43 Bleibt die Frage, wie man das alles in ein Projekt bekommt, das seit drei Jahren läuft und beim ersten Lauf zwölfhundert Meldungen produziert. Genau da entscheidet sich, ob ein Regelwerk gelebt wird oder in der ersten Woche wieder abgeschaltet ist. Die Antwort darauf ist erfreulich unspektakulär — und sie funktioniert ohne Aufräum-Projekt und ohne Genehmigung.

15:04 Zwei Dinge stecken in dieser Definition. Erstens die Alternative: ein neueres Plugin, das Typinformationen mitliest und dadurch Dinge erkennen kann, die allein aus dem Code nicht ersichtlich sind. Es ist zurückhaltender in seinen Meldungen — für neue Projekte einen Blick wert. Zweitens, und praktisch wichtiger, das schrittweise Vorgehen.

15:23 Der Gedanke ist derselbe wie bei einer Renovierung im bewohnten Haus: Man reißt nicht alles gleichzeitig auf. Erst sichtbar machen, dann eine Grenze ziehen, dann Raum für Raum sanieren. Der dritte Punkt ist der eigentliche Trick, und er ist bestechend einfach. Sie messen den Ist-Zustand — sagen wir zwölfhundert Warnungen — und legen fest, dass es nicht mehr werden dürfen.

15:45 Ab diesem Moment ist das Problem eingefroren: Alter Code darf bleiben, neuer Code muss sauber sein. Sie brauchen kein Aufräum-Projekt und keine Genehmigung dafür, und trotzdem geht die Zahl mit jeder Berührung einer Datei nach unten. Das ist die pragmatischste Antwort auf gewachsenen Code, die ich kenne. Der vierte Punkt verdient eine Warnung. Automatische Korrekturen sind eine großartige Sache, aber sie sind nicht alle gleich harmlos.

16:11 Manche ändern nur Formatierung, andere strukturieren Code um — und in seltenen Fällen ändert sich dabei das Verhalten. Lassen Sie die Korrekturen also in einem eigenen Schritt laufen und schauen Sie sich die Änderungen an, bevor sie eingecheckt werden. Der letzte Punkt ist der Schritt zur Reife: Die Konfiguration als eigenes Paket, das alle Projekte einbinden — eine Änderung, alle profitieren.

16:34 Zwei Befehle, die zusammen die ganze Strategie tragen. Der obere ist der Wächter für die Bauleitung: Er lässt keine einzige neue Warnung durch. Setzen Sie die Zahl auf Ihren gemessenen Ist-Stand, und senken Sie sie, wenn Sie aufgeräumt haben — jede Senkung ist ein kleiner sichtbarer Fortschritt. Der untere ist die Korrekturhilfe, die Ihnen den mechanischen Teil abnimmt. Beide zusammen machen aus einem unüberschaubaren Berg eine Aufgabe, die man nebenher erledigt.

17:02 Zum Abschluss entwerfen Sie den Plan für ein echtes Bestandsprojekt. Das Erfolgskriterium nennt drei Dinge, und das dritte ist das, was am häufigsten fehlt: benannte Verantwortliche. Ein Regelwerk ohne jemanden, der sich zuständig fühlt, veraltet still — irgendwann meldet es etwas Unpassendes, jemand schaltet es ab, und niemand merkt es.

17:21 Legen Sie also fest, wer die Konfiguration pflegt und wo neue Regeln diskutiert werden. Das ist unspektakulär und entscheidet darüber, ob der heutige Tag in einem Jahr noch Wirkung hat. Der erste Punkt ist der klassische Fehlstart: Man aktiviert alles auf einmal, der Bau schlägt fehl, das Team ist blockiert — und am nächsten Morgen ist die Konfiguration wieder ausgeschaltet.

17:43 Danach ist das Thema für ein Jahr verbrannt, weil jeder es mit dem chaotischen Tag verbindet. Der dritte Punkt ist die stille Variante des Scheiterns: Ohne eine harte Obergrenze wachsen Warnungen einfach weiter, bis sie niemand mehr liest. Beides sind keine technischen Probleme, sondern Fragen der Einführung. Schauen wir zurück. Die Konfiguration ist heute ein einfaches, geordnetes Feld von Blöcken — mit zwei Einstellungen, die man nicht vergessen darf.

18:09 Das empfohlene Regelwerk fängt echte Fehler, und was in TypeScript überflüssig ist, kommt weg, damit die Meldungen wieder ernst genommen werden. Formatierung übernimmt ein Formatierer. Die Hook-Regeln sind nicht verhandelbar, die neue Compiler-Diagnostik nehmen Sie als Geschenk mit. Und die Einführung läuft schrittweise, mit einer eingefrorenen Grenze statt eines Aufräum-Projekts.

Fragen & Weiterarbeiten

18:32 In der Freigabe finden Sie ein Spickzettel-Blatt und die Beispielkonfigurationen — nehmen Sie sich die kommentierte Fassung mit, sie ist als Vorlage für Ihre eigene Begründungsdatei gedacht. Für den Blick nach vorn lohnt sich die Seite des neueren Plugins; die Dokumentation der klassischen Plugins ist der Ort, an dem Sie einzelne Regeln nachschlagen.

18:51 Wenn im eigenen Projekt eine Regel Ärger macht und Sie unsicher sind, ob abschalten richtig ist: Fragen Sie uns lieber einmal zu viel. Vielen Dank.