Das Pferd ist totschrei: Übergang von Tslint zu Eslint

Bis vor kurzem haben die Entwickler von Dodo Pizza Engineering in allen Frontprojekten tslint verwendet - ein nützliches Tool, das Ihnen sagt, wann Sie den Code durcheinander gebracht haben, Ungenauigkeiten gemacht hat, den Code im gleichen Stil beibehält und viele Kommentare korrigiert. Aber dann nahm Tslint und starb. Unter dem Schnitt werde ich Ihnen sagen, warum es passiert ist, wie Sie aufhören können, Tränen über den Verstorbenen zu gießen, zum Eslint-Werkzeug wechseln und auch etwas sehr Intimes zeigen.



Tatsächlich hat alles vor langer Zeit begonnen: Die letzte Veröffentlichung des tslint-Kernels war bereits 2016. Und dies ist der Moment, in dem es Zeit ist, "last" zu sagen, wenn jemand immer noch "last" sagt, weil diese Veröffentlichung wirklich die letzte war. Am 19. Februar 2019 wurde ein offizieller Beitrag veröffentlicht, um die Entwicklung von tslint zu stoppen. Darin rät die Entwicklungsfirma (übrigens nicht einmal Microsoft) allen dringend, auf eslint umzusteigen, da ihre Bemühungen nun darauf abzielen, die TypeScript-Unterstützung in diesem Linter zu verbessern.

Eine Sprache, ein Stapel, eine Community

Microsoft sieht in TypeScript die wichtigste Webentwicklungssprache, die Java / ECMA Script ersetzen sollte. Offensichtlich impliziert ein solch ehrgeiziges Ziel einen einzigen Werkzeugstapel für die gesamte Front-End-Entwicklung. Dies sollte die Migration der großen JS-Community zu TypeScript erheblich vereinfachen. Neben der Vertrauensgarantie von Microsoft verfügt eslint über eine bessere Architektur als tslint. Sie können beispielsweise Parser verbinden, und es stehen mehr verbundene Regeln zur Auswahl.

Microsoft wäre nicht selbst, wenn es nur gewollt wäre. Was auch immer wir über die Qualität ihrer Software sagen, sie bieten großartige Entwicklungswerkzeuge (und übrigens Eingabegeräte). Diesmal kamen sie also nicht mit leeren Händen, sondern schrieben einen Migrationsplan . In Übereinstimmung mit diesem Plan wurde die Entwicklung von tslint-Regeln bereits am 1. August 2019 eingestellt, und die Entwicklung von tslint selbst wird am 1. November 2019 eingestellt. Um ehrlich zu sein, wurde die Entwicklung vor langer Zeit eingestellt (siehe oben für die neueste Version).

Hier sollte dem Leser klar werden, dass es Zeit ist, auf eslint umzusteigen, es gibt keine andere Wahl. Um die Pille zu versüßen, lohnt es sich zu sagen:

• Während sich tslint auf TypeScript konzentriert, wobei der Schwerpunkt auf der korrekten Verwendung von Typen und der Syntaxprüfung liegt, deckt eslint alles ab, was im Vordergrund stehen kann, einschließlich der Syntax von React-Komponenten.
• eslint hat viel mehr vordefinierte Regeln;
• Es gibt Regeln (und Plugins), die den Code auf Blockebene überprüfen (Codeduplizierung, wahrgenommene Komplexität usw.).
• Es gibt Plugins, die überhaupt keinen Code prüfen, sondern beispielsweise reguläre Ausdrücke.

Im Allgemeinen sieht es so aus, als würde der Übergang zu einem neuen Linter, der ein Mainstream-Produkt ist, uns eine ganze Welt bisher ungesehener Möglichkeiten eröffnen. Lass es uns versuchen!

Fügen Sie dem Projekt eslint hinzu

Ich werde im Folgenden auf die Migration von Regeln eingehen. Richten Sie in der Zwischenzeit ein Projekt für die Arbeit mit eslint ein.
Wenn Sie bereits ein Projekt mit tslint haben, entfernen Sie zuerst alle Pakete, die sich auf tslint beziehen: tslint selbst, tslint-react, tslint-config-prettier usw.

Fügen Sie nun dem Projekt eslint-Pakete hinzu (setzen Sie alles als devDependencies):

• eslint selbst;
• @ typescript-eslint / parser - Engine zum Parsen von TypeScript;
• @ typescript-eslint / eslint-plugin - Regelsätze für TypeScript

Eslint minimales Setup

Erstellen Sie die Konfigurationsdatei .eslintrc.json. Eslint unterstützt viele Dateiformate für seine Konfiguration, aber JSON scheint am bequemsten zu sein. So sieht die minimale Arbeitsoption aus:

{ //   "env": { //    "browser": true, //   ES6 "es6": true, //   ES2017 "es2017": true }, //   "extends": [ //    eslint "eslint:recommended", //      "plugin:@typescript-eslint/eslint-recommended", //    TypeScript "plugin:@typescript-eslint/recommended", //  TS,     "plugin:@typescript-eslint/recommended-requiring-type-checking" ], //   "parser": "@typescript-eslint/parser", "parserOptions": { //    TS     "project": "tsconfig.json", "tsconfigRootDir": ".", }, //      TypeScript "plugins": ["@typescript-eslint"], "rules": {} } 

Der env Abschnitt informiert eslint über Ihre Projektoptionen. In meinem Beispiel ist dies ein Projekt für den Browser (d. H. Der Code funktioniert im Browser). Schreiben Sie für Node.JS - setzen Sie node: true. Die beiden folgenden Optionen geben den Dialekt des zu testenden JS an. Im Allgemeinen überprüfen wir den Code auf TypeScript. Wenn Ihr Projekt jedoch auch Code für JS enthält, vergessen Sie nicht, diese zu verschärfen. Für uns selbst haben wir beschlossen, diese Parameter auf den gleichen Wert wie das Ziel in tsconfig.json festzulegen.

Die Standard-Eslint-Regelsätze sind nicht umstritten, wie das erforderliche Semikolon am Ende von Ausdrücken oder Leerzeichen / Tabulatoren. Alle Regeln sind einzigartig nützlich. Hier können Sie sehen, welche Regeln und mit welcher Stufe enthalten sind .

In der nächsten Zeile müssen Sie die Hälfte der Regeln deaktivieren . Dies ist erforderlich, da sie nicht mit TypeScript funktionieren und statt normal zu arbeiten, eine Reihe von Fehlern auslösen.

Dann sollten Sie die empfohlenen Regeln von TypeScript in einer separaten Tasche verbinden. Hier müssen Sie berücksichtigen, dass allgemeine Syntaxregeln (wie das Verbot von var) so funktionieren.

Für Regeln, die TS-Typen verwenden (z. B. @ typescript-eslint / no-unnötig-type-assertion), wird die TypeScript-Engine benötigt. Und die Engine benötigt die Datei tsconfig.json, deren Pfad angegeben werden muss.

In tsconfig.json geben wir bei Dodo Pizza Engineering normalerweise Ausschluss- und Auswurftests an, damit sie nicht mit dem Projekt erstellt werden. Damit eslint funktioniert, müssen Sie angeben und einschließen. Das heißt, alle Dateien, die fusselfrei sein müssen, müssen explizit in das Projekt aufgenommen werden. Ohne dies schwört eslint bei jeder gefundenen Datei: "Die Datei befindet sich nicht im Projekt, ich werde nichts tun, ich werde eine Reihe von Fehlern werfen." Es gibt eine Option ohne explizite Angabe von Projektdateien - legen Sie den Parameter createDefaultProgram: true . Dies bedeutet im Wesentlichen: "Alles, was Sie finden, ist Parsi." Entwickler raten jedoch dringend davon ab, da die Leistung erheblich abnimmt.

Wenn Sie ForkTsCheckerWebpackPlugin zum Verarbeiten von TypeScript-Dateien verwenden, ersetzen tslint: true eslint: true in seinen Parametern durch eslint: true (in webpack.config.ts).

Es lohnt sich auch, den Start des Linter über die Befehlszeile einzurichten. package.json Sie diesen Wert zuvor dem package.json in package.json :

 "eslint": "eslint --cache --ext .js,.jsx,.ts,.tsx src", "eslint:dump": "eslint --print-config ./.eslintrc.json", 

Die erste Zeile startet nur die Eslint-Prüfung, ohne das Projekt zu erstellen. Die zweite zeigt die aktuellen Eslint-Einstellungen an, mit denen Sie die Einstellungen für die Regelparameter anzeigen können.

In dieser Version funktioniert eslint bereits im Projekt und fängt sogar einige Schwärme ab: Neudefinition von Globals, nicht verwendeten Variablen usw.

Einrichten von Visual Studio Code

Nachdem Sie diesen Weg zurückgelegt haben, können Sie den Linter bereits über die Befehlszeile starten. Es wird auch implizit beim Erstellen des Projekts gestartet. In Visual Studio Code werden jedoch keine Kommentare vom Linter angezeigt. Wie so ?!

Es gibt ein Eslint-Plugin für das Studio (dbaeumer.vscode-eslint), das installiert werden muss. Danach wird sowieso nichts mehr funktionieren, nichts wird hervorgehoben und korrigiert. Warum? Weil das Plugin eine Konfiguration hat, die besagt, dass Sie nur in JavaScript-Dateien arbeiten müssen.

Diese hinterhältige Einstellung wird nicht in der Benutzeroberfläche vorgenommen. Sie müssen daher in die Studio-Einstellungsdatei gehen und die benötigten Sprachen manuell zum Parameter eslint.validate hinzufügen. Eine vollständige Liste der Sprachen finden Sie im Darm der Studiodokumentation. So sieht diese Einstellung bei uns aus:

 "eslint.validate": [ "javascript", "javascriptreact", "typescriptreact", "typescript", ], 

Starten Sie danach das Studio neu und alles wird endlich funktionieren.

Jetzt müssen die Regeln noch konfiguriert werden

Das Projekt ist eingerichtet. Nun zu den Regeln, denn im obigen Beispiel war die Liste der Regeln leer.

Ich muss sagen, dass tslint uns nicht davon abgehalten hat, formal korrekten Code durcheinander zu bringen. Vergessen Sie zum Beispiel das Warten. Eslint ist in der Lage, solche semantischen Fehler zu finden und sie zu beschwören: zu informieren, dass der Rückgabewert Versprechen ist, aber aus irgendeinem Grund wird das Warten nicht geschrieben. Dies schließt auch Stilprobleme mittlerer Komplexität ein: die Verwendung eines Lambda oder einer Funktion usw., die Prettier nicht mehr ausführen kann.

In Bezug auf einfache Regeln: Position der Klammern, Tabulatoren vs. Räume usw. wird angenommen, dass sie Prettier oder einem ähnlichen Paket gegeben werden sollten. Aber im Linter sollten sie trotzdem bleiben: Dies ist die letzte Grenze, die den nachlässigen Entwickler der gefallenen Projektbaugruppe noch aufhalten kann. Darüber hinaus kann diese Zeile automatisiert werden: Mit Husky können Sie beispielsweise den Linter für jedes Commit automatisch starten.

Wir haben beschlossen , keinen der vorhandenen tslint-Regelsätze zu migrieren . Und erstellen Sie Ihr eigenes Set von Grund auf neu.

Es gibt vordefinierte Regelsätze für eslint:

• ESLint Recommended ist ein neutrales Regelwerk, das mit der Idee erstellt wurde, keine Holivars zu erzeugen. Es sind nur offensichtlich notwendige Überprüfungen enthalten: nicht verwendete Variablen usw. Alle nachfolgenden Sätze erweitern diesen.
• Google - es gibt bereits einen Grund für holivar: Zum Einrücken gibt es ausschließlich Leerzeichen, ein Semikolon ist erforderlich.
• AirBnB - Es gibt auch strenge Stilregeln, einschließlich eines obligatorischen Semikolons.
• Standard - Semikolons sind hier verboten, aber auch nachgestellte Kommas sind verboten.

Die vorgefertigten Pakete haben uns nicht gefallen. Das mag seltsam klingen, aber es ist wichtig, dass wir zu einem neuen Linter wechseln, um Stilkriege zu vermeiden. Wenn wir überall so schreiben (Tabulatoren ohne Semikolon, nachgestellte Kommas sind obligatorisch), lassen Sie es so - die Hauptsache ist, dass es in allen Projekten gleich ist.

Versprochener Sex: eigene Regeln

Ehrlich gesagt ist es wie ein Mädchen, das Brüste zeigt, wenn man seinen Eslint-Regelsatz zeigt: Es gibt keine Geheimnisse mehr. Ich habe lange darüber nachgedacht, ob es sich lohnt, dies zu tun. Aber nach Rücksprache mit anderen Mädchen entschied ich, dass es sich lohnt.

Ich beginne mit den Plugins, die wir verwenden:

• React - Überprüft den Code der Reaktionskomponente. Grundregeln plus unsere. Vom Wichtigen: Wir ertrinken für reine Funktionskomponenten;
• React-Hooks - Regeln von React-Entwicklern zur Verwendung von Hooks;
• Versprechen - prüft auf häufige Fehler bei der Verwendung von Versprechen. Mit TypeScript-Code funktioniert das etwas seltsam. Aus dem Wichtigen: Wir versuchen, Promise überall zu verwenden und keine Rückrufe und dann / catch zu verwenden, da der Code besser lesbar ist.
• Optimize-Regex ist ein unterhaltsames Plugin, das Tipps zur Verbesserung regulärer Ausdrücke gibt. Nicht sehr nützlich, weil Regexp wir ein bisschen haben. Aber bei weitem nicht alle besitzen Regexp-Magie. Es ist also nützlich, aber es wird nicht viel gefragt.
• sonarjs ist ein Fire-Plugin mit Überprüfungen der Codekomplexität und typischen Refactoring-Fehlern. Das erste ist eine lustige Sache: Das Plugin bewertet die wahrgenommene Komplexität des Codes und gibt Ratschläge, wenn es sich lohnt, den Code zu vereinfachen. Die Suche nach Refactoring-Fehlern ermöglicht häufig auch die Vereinfachung des Codes oder zumindest die Verbesserung der Lesbarkeit.
• @ typescript-eslint - eslint-Regeln zum Überprüfen des TypeScript-Codes. Und ein Satz zum Deaktivieren von Grundregeln, die nicht mit TS kompatibel sind.

Unsere gesamte Regeldatei ist hier . Ich stelle fest, dass es kein Dogma ist und aktualisiert wird, wenn es sich an Projekte anpasst.