Die Hauptlaufzeit mit einem gut ausgewählten Satz von integrierten Regeln. Anpassend mit Ihren eigenen Regeln, Prozessoren, Formattern, gemeinsam genutzbaren Konfigurationen und Plugin -Modulen.
In den DOCs finden Sie eine detaillierte Erläuterung der verfügbaren Regeln, Konfiguration und Nutzung.
Vé
Offizieller Prozessor für Vue -Einzeldateikomponenten (SFC). Extrahiert den Skriptinhalt aus Ihren *.vue -Dateien zum Linieren.
Heimdall
Kompatibilitätsebene, um die Verwendung von Tslint -Regeln und -Forten innerhalb der Wotan -Laufzeit zu ermöglichen.
Valtýr
Lassen Sie Wotan fast wie Tslint verhalten. Verwenden Sie Ihren vorhandenen tslint.json ohne Änderung wieder.
Bifröst
Ermöglicht Autoren von Tslint -Regeln und -Forten, ihr Paket für die Verwendung in Wotan bereitzustellen. Regeln und Formatierungen, die BIFRORT verwenden, brauchen Heimdall nicht, um korrekt zu funktionieren.
Ymir
Bietet Kerntypen für benutzerdefinierte Regeln und Plugin -Autoren.
Mímir
Enthält alle Kernregeln, Formatter und Konfigurationsvoreinstellungen.
Mithotyn
Sprachservice -Plugin für Typscript. Bietet eine Echtzeit-In-Editor-Linie, während Sie eingeben.
Weitere Dokumentation
Verständnis der API von TypeScript
Schreibregeln
Testregeln
Verwenden lokaler Regeln
Schreiben von gemeinsam genutzbaren Konfigurationen
Verwenden der API
Rezepte
LINTING VUE -Dateien mit Tslint -Regeln
Ersatz für tslint --type-check
Erkennen Sie ungenutzte Variablen
Worum geht es?
Was ist mit diesen Namen los?
Nordische Mythologie:
Fimbulinter stammt aus Fimbulwinter, dem schrecklichen 3 -jährigen Winter, der den Ereignissen von Ragnarök vorausgeht. "Fimbul" bedeutet "The Great", "Linter" ist ein Werkzeug, das bestimmte Codierungsmuster erkennt und warnt.
Wotan ist einer der vielen Namen von Odin, dem Allvater. Sie können ihn auch unter dem Namen Woden, Wodan, Wensley usw. kennen. Woden ist ein Opfergott, blutrünstig und grausam. Er strebt ständig nach Weisheit. Von seinem Thron kann er alles in den neun Welten sehen.
Vé ist der jüngste der drei Störungen Woden, Vili und Vé, die zusammen das riesige Ymir töteten und die neun Welten aus seinem Körper schuf.
Für das erste menschliche Paar, Ask und Embla, gab Odin Seele und Leben; Vili gab Witz (Intelligenz) und Berührungsgefühl; und Vé gab das Gesicht (Aussehen, Gesichtsausdruck), Sprache, Hören und Anblick.
Heimdall (auch als Heimdallr bekannt), wo sich die brennende Regenbogenbrücke Bifrösten himmelt, hält den Auftreten von Ragnarök auf.
BifrOst ist die brennende Regenbogenbrücke, die die Welt der Menschen mit dem Reich der Götter verbindet.
Valtýr , aus "Valr" (die Toten, im Kampf getötet) und "Týr" (Gott), bedeutet Gott der Ermordung und wird oft verwendet, um sich auf Odin zu beziehen.
Ymir ist der Riese, dessen Körper die ganze Welt geschaffen wurde. Er ist der Vorfahr aller Jötnar.
Mímir ("The Rememberer, der Weise"), der für sein Wissen und seine Weisheit bekannt ist. Der Gott Odin trägt Mímirs Kopf und es rezitiert ihm geheimes Wissen und Rat.
Mithotyn (eigentlich "Mitoðinn", was "Spender des Schicksals" bedeutet) führt Regeln ein, in denen es keine gab. Füllt Odins Platz während seiner Reisen in ausländische Länder.
Warum noch ein Linter?
Dieser versucht, Designentscheidungen anderer Linter zu vermeiden, die sich als problematisch herausstellten:
Vermeiden Sie Namenskonflikte, indem Sie Regelnamen je nach dem Paket, aus dem sie stammen, Voraussetzungen vorangestellt.
Tslint stellt alle Regeln in einen globalen Namespace ein und durchsucht sie in allen verfügbaren Regeln. Die Reihenfolge der Verzeichnisse ist wichtig, während die Kernregeln Vorrang haben.
Eslint ermöglicht ein lokales Regelnverzeichnis als CLI -Flag. Regeln in diesem Verzeichnis können Kernregeln außer Kraft setzen.
Die Abhängigkeiten von Konfigurationsdateien werden relativ zu dieser Datei behoben.
Tslint macht das schon.
Eslint unterstützt das nicht.
Keine Unterscheidung zwischen gemeinsam genutzbaren Konfigurationen und Plugins. Tatsächlich handelt es sich nur um erweiterbare Konfigurationen, die optional Regeln Verzeichnisse, Einstellungen, Regeln und Prozessoren bereitstellen können.
Mit TSLINT können Sie zwischen extends und rulesDirectory wählen. Das Regelnverzeichnis eines Pakets ist ein Implementierungsdetail und sollte nicht Teil der Konfiguration des Benutzers sein.
Eslint verarbeitet Konfigurationen und Plugins ganz anders. Tatsächlich versuchten sie, gemeinsam genutzbare Konfigurationen zugunsten von Plugins abzubauen.
Faule Belastung von Regeln zur Reduzierung der Startzeit.
Tslint macht das schon.
Eslint erwartet, dass Plugins die Regeln als bereits geladene Objekte bereitstellt. Das verursacht viel Gemeinkosten, wenn Sie nur ein paar Regeln eines großen Pakets verwenden.
Zwischenzugriff und Konfiguration des Dateisystems. Da der Cache ein DI -Dienst ist, können API -Benutzer den Cache bei Bedarf löschen.
Unterstützung für Prozessoren von Anfang an. Aktivieren von *.vue -Dateien und vielem mehr.
Aliase für Regeln mit Konfiguration. Kann verwendet werden, um Regeln wie Eslints no-resticted-syntax als bestimmte benannte Regeln für jede Konfigurationsoption zu behandeln.
Die gesamte API wird von einem DI -Behälter angetrieben. Das macht es einfach, einen anderen Service zu injizieren. Sie können sogar Plugins über die CLI verwenden, um verschiedene Dienste zu injizieren.
"Globale" Konfigurationsdatei (neben .wotanrc.yaml ) für CLI -Standard- und Plugin -Konfiguration: .fimbullinter.yaml . Diese Datei kann auch von Editor -Plugins verwendet werden, sodass keine gemeinsame Konfiguration dupliziert werden muss.
Eslint hat keine solche Datei und lehnte es ab, in Zukunft eines hinzuzufügen. Tools wie standard oder xo müssten nicht existieren, wenn Sie nur eine solche Konfigurationsdatei mit CLI -Standards erstellen müssten.
Tslint starten, um es in ihren tslint.json zu stopfen, was zu verwirrten Benutzern führt.
Melden Sie unbenutzte und überflüssige Aktivitäten und deaktivieren Sie Kommentare (oder Teile davon) mit --report-useless-directives .
Eslint berichtet, dass nur nicht verwendete Deaktivierungskommentare. Es berichtet nur Kommentare, die völlig ungenutzt sind. Überflüssige Kommentare werden nicht so gut gemeldet und aktivieren Kommentare für nicht existierende Regeln.
Tslint unterstützt das nicht.
Unterschiede zu Tslint
Um ein Plugin oder eine gemeinsame Konfiguration zu erweitern, verwenden Sie extends: plugin-name . Der Name wird gemäß dem Modulauflösungsalgorithmus des Knotens relativ zur Konfigurationsdatei gelöst.
Um Regeln in Ihrem Projekt zu verwenden, verwenden Sie rulesDirectory: {"my-prefix": "./path/to/rules"} und konfigurieren Sie sie als my-prefix/rule-one: "error" . Das Regelnverzeichnis ist ein Pfad relativ zur Konfigurationsdatei.
Überschreibungen: Sie können die Haupt -Cofiguration überschreiben, indem Sie einen oder mehrere Überschreibungen angeben. Wenn der Dateiname mit dem Glob -Muster der Überschreibung übereinstimmt, werden alle Einstellungen dieser Überschreibung angewendet. Überschreibungen werden in der Reihenfolge verarbeitet, später Überschreibungseinstellungen von vorhergehenden Überschreibungen.
Muster stimmen relativ zu der Konfigurationsdatei überein, in der sie angegeben sind.
Muster ohne Schrägstrich werden nur gegen den Grundnamen jeder Datei abgestimmt.
Um eine Übereinstimmung mit dem aktuellen Verzeichnis zu beschränken, werden Sie das Muster mit ./ .
Negierte Muster können verwendet werden, um von den Übereinstimmungen der vorhergehenden Muster zu subtrahieren.
linterOptions.exclude -> exclude
Ausgeschlossene werden bei der Erweiterung einer Konfiguration nicht überschrieben.
Das Musteranpassung folgt den gleichen Regeln wie Überschreibungen (siehe oben).
JSON5 -Unterstützung für Konfigurationsdateien.
Regelunabhängige Einstellungen, die Regeln und Prozessoren abholen können.
Prozessoren, sogar Unterstützung --project .
Aliase, siehe oben
Ein vernünftiger und sicherer Ansatz zur Behebung:
Behebt Dateien nicht mit Syntaxfehlern.
Ausgeschlossen überlappende Ersatze, um zu verhindern, dass Sie Ihren Code zerstören.
Führt eine konfigurierbare Anzahl von Iterationen pro Datei aus, um widersprüchliche Änderungen in der nächsten Iteration anzuwenden.
Stopps, wenn Korrekturen Syntaxfehler einführen würden.
Das Fixieren mit --project erzeugt das gesamte Programm nicht von Grund auf neu, wodurch es einfach schnell macht.
Testen
Tests werden in JSON -Dateien konfiguriert, mit denen Sie alles konfigurieren können, was Sie durch die CLI angeben können
Testdateien enthalten kein Fehlermarkup. Dies vermeidet Syntaxfehler und erleichtert sie leichter aufrechtzuerhalten. FININT -Ergebnisse und feste Inhalte werden in separaten Basisdateien gespeichert.
Der gleiche Code kann mit unterschiedlichen Einstellungen getestet werden.
Unterstützt TypeScript -Projektreferenzen.
Laden Sie Standardwerte für CLI -Optionen von .fimbullinter.yaml .
Verwendet keine Typinformationen in deaktivierten JavaScript-Dateien ( // @ts-nocheck oder "checkJs": false ).
Berichte ungenutzte und überflüssige Aktivitäten ermöglichen und deaktivieren Sie Kommentare mit --report-useless-directives .
Unterstützte Umgebungen
Dieses Projekt läuft auf allen aktiv unterstützten Versionen von Node.js.
Dieses Projekt unterstützt offiziell die neueste 3 stabile Version von TypeScript. Zum Schreiben ist dies 3.0 - 3.2. Es sollte mit den nächtlichen Builds von TypeScript ( typescript@next ) funktionieren, es gibt jedoch keine Garantie.
Benutzerdefinierte Regeln sollten zumindest ES6 verwenden, um native Klassen zu unterstützen. Andernfalls haben Sie Probleme, wenn Sie versuchen, Klassen zu erweitern, die aus einem der Pakete exportiert wurden.
Semantische Versioning (SEMVER -Richtlinie)
Euen Die folgende Richtlinie gilt nur für die noch kommenden 1.x und folgenden Veröffentlichungen. Jede Freisetzung im Bereich 0.x wird als experimentell angesehen. Es kann und wird die API -Veränderungen ohne Abschaltung geben.
Theoretisch kann jede Änderung zu einer Regel Benutzer brechen und kann als eine sprechende Veränderung angesehen werden. Um zu vermeiden, dass eine neue Hauptversion für jede Fehlerbehebung veröffentlicht wird, haben wir leicht unterschiedliche Richtlinien, wie unten beschrieben.
Vorversion (nächtliche Builds)
sind nicht garantiert stabil
Markiert als next auf NPM, damit Sie @fimbul/wotan@next installieren können
Enthält die neuesten Änderungen für die nächste Veröffentlichung
x.0.0-dev* enthält alle Änderungen, einschließlich Breaking-für die nächste Hauptversion
xy0-dev* enthält alle Änderungen für die nächste kleine Version
Es gibt keine Vorversion für Patch -Versionen
Patch -Veröffentlichungen
Behebung von Abstürzen
Behebung Regressionen
Refactorings interner Funktionen, die nicht das Verhalten des Benutzers verändern
Kleinere Veröffentlichungen
Fügt neue Regeln, Regeloptionen, Formatter, Prozessoren, APIs hinzu
Regeln können neue Schecks hinzufügen, die zu neuen Ergebnissen führen können
Neue Regeln und Optionen sind in wotan:latest
Regeln können ihre Auffindungsnachrichten ändern
Die für die menschlichen Verbrauch (z. B. stylish ) vorgesehenen Formatterer können ihre Ausgabe ändern
Regeln, Regeloptionen, Formatter, Prozessoren und APIs können veraltet werden
Konfigurationsdateien können neue Konfigurationsoptionen hinzugefügt werden
Hauptveröffentlichungen
Enthält brechen API -Änderungen
Entfernt bisher veraltete Regeln, Optionen, Formatierungen usw.
Für den Maschinenverbrauch (z. B. json oder tap ) bestimmte Formattere können ihre Ausgabe ändern
wotan:recommended wird auf den Inhalt von wotan:latest
Freigabeplan
Derzeit gibt es keinen festen Veröffentlichungsplan. Nightly Builds werden jeden Abend veröffentlicht, wenn es Änderungen am Master gibt. Patch -Veröffentlichungen werden veröffentlicht, sobald Fehler identifiziert und behoben werden. Minderjährige Veröffentlichungen werden alle ein oder zwei Wochen veröffentlicht, wenn Änderungen am Master vorhanden sind. Es werden wichtige Veröffentlichungen veröffentlicht, sobald sich die Veränderungen ausreichend verändert haben.
