CSS mit Stylelint linten

Sie schreiben CSS. Wahrscheinlich viel CSS. Und Sie machen Fehler. Wahrscheinlich viele Fehler. Jemand muss Sie davon abhalten, Fehler in Ihrem CSS zu machen.

Manchmal ist dein Fehler ein echter Bug. Manchmal ist es einfach nur schludriger, inkonsistenter oder unklarer Programmierstil. Einige davon mögen auf den ersten Blick trivial erscheinen (abhängig von deinem Temperament), aber sie werden offensichtlich wichtig, wenn die Codebasis wächst und altert, wenn mehr Leute Hand anlegen und hässliche Dinge tun. Dinge, die du für unvorstellbar hieltest.

Du versuchst, dich zu beherrschen. Deine Kollegen helfen auch mit und korrigieren dich, wenn du abweichst. Aber sowohl du als auch deine Kollegen sind fehlerhaft, also werdet ihr natürlich, zwangsläufig scheitern, zumindest teilweise. Und später wirst du oder irgendein anderer leidender Narr die Konsequenzen dieser Fehler tragen, die in dein CSS geraten sind.

Weder du noch deine Kollegen reden gerne über die Fehler, die ihr gemacht habt. Es ist umständlich. Manchmal ist es entmutigend und spaltend. Bestimmte Konventionen, die der Codebasis definitiv helfen, wie konsistente Formatierung, mögen pedantisch und mühsam erscheinen, wenn sie manuell durchgesetzt werden. Oder sie bringen die aufdringlichen und starrköpfigen Elemente in Menschen hervor, die du normalerweise magst.

Außerdem würdest du lieber sofort korrigiert werden, als auf eine Code-Review zu warten, nur damit jemand darauf hinweisen kann, dass du eine Deklaration dupliziert hast und deinen Abstand bereinigen solltest. Sofortiges Feedback würde dir helfen, Konventionen zu verinnerlichen und etwas weniger Zeit damit zu verschwenden, herumzustochern, wenn dein CSS nicht funktioniert.

Was du wirklich brauchst, ist eine fehlerverhindernde Maschine

Du brauchst eine zuverlässige fehlerverhindernde Maschine, die CSS versteht und dich versteht: deine Absichten, Vorlieben, Ideale und Schwächen.

Eine solche Maschine hätte ihre Grenzen. Alles hat seine. Aber ihre Grenzen wären anders als die von dir und deinen menschlichen Kollegen. Welche Fehler sie auch immer verhindern *kann*, sie wird sie konsequent und unermüdlich verhindern. In der Zwischenzeit kannst du und deine Kollegen daran arbeiten, die Maschine zu verbessern, ihre Fähigkeiten zu erweitern und ihre Grenzen zu verringern. Wenn sie Open Source ist, können andere Mitwirkende aus aller Welt sich anschließen – andere fehlbare CSS-Autoren, die gleichermaßen daran interessiert sind, ihre eigenen Fehler zu verhindern.

CSS-Autoren brauchen Linters genauso wie jeder andere auch

Wir nennen diese fehlerverhindernden Programme „Linters“. JavaScript hat mehrere gute. ESLint im Besonderen leistet Wunder, zeigt uns allen, wie hilfreich ein guter Linter sein kann. Aber im Bereich CSS waren wir nicht so glücklich. Wir hatten sehr begrenzte Optionen: den Ruby-basierten, präprozessor-spezifischen scss-lint und den älteren CSS Lint.

Aber das war vor dem Aufkommen von PostCSS. Unter anderem *stellt PostCSS die Mittel zur Verfügung, um interoperablere CSS-Tools zu entwickeln*. Es kann jede CSS*-ähnliche* Syntax in einen Abstract Syntax Tree (AST) parsen, den Plugins analysieren und manipulieren können. Und mit benutzerdefinierten Parsers kann PostCSS sogar nicht standardmäßige, technisch „ungültige“ Muster (wie `//`-Kommentare) verarbeiten.

Die Bedingungen sind reif für einen mächtigen neuen Stylesheet-Linter – angetrieben von PostCSS und inspiriert von den besten Funktionen von scss-lint und ESLint.

Ich habe mit einigen Mitarbeitern an diesem Projekt gearbeitet und schreibe jetzt, um Ihnen das von uns entwickelte Tool vorzustellen: stylelint.

Einige Dinge, die du mit stylelint machen kannst

Was folgt, ist ein Versuch, die Funktionen von stylelint zusammenzufassen, die über *hundert* Regeln und eine gründliche Erweiterbarkeit umfassen.

Wenn du zu irgendeinem Zeitpunkt ungeduldig wirst („Okay, okay: Ich bin überzeugt, dass stylelint Wunder wirkt. Keine Zusammenfassung mehr nötig.“), springe einfach zum nächsten Abschnitt, wo ich einige Fragen vorwegnehmen und einige Tipps geben werde.

#1) Fehler erkennen

Einige stylelint-Regeln zielen darauf ab, offensichtliche Fehler zu erkennen, meist Tippfehler oder Übersehenheiten, die gemacht wurden, wenn du in Eile, abgelenkt oder schläfrig warst. Zum Beispiel kannst du leere Blöcke, ungültige Hex-Werte, doppelte Selektoren, unbekannte Animationsnamen und fehlerhafte linear-gradient-Syntax verbieten.

Andere Regeln tun ihr Bestes, um subtilere Fehler zu erkennen.
Es gibt eine Regel, die warnt, wenn du eine Kurzschreibweise für Eigenschaften (wie `margin`) verwendet hast, die eine ihrer Langformen (wie `margin-top`) überschreiben wird, was du wahrscheinlich unabsichtlich getan hast. Und es gibt eine Regel, die dich vor der verwirrenden Situation warnt, wenn Regel A vor Regel B kommt, aber tatsächlich Regel B überschreibt, weil die Selektor von Regel A eine höhere Spezifität hat (z.B. Regel A ist `.foo.bar {...}` und Regel B ist `.foo {...}`). Das ist ein kniffliger.

Eine weitere Regel verwendet das PostCSS-Plugin doiuse, um zu überprüfen, ob deine Stile für die Browser funktionieren, die du unterstützen möchtest. Und wieder eine andere verwendet css-colorguard, um Farben zu beanstanden, die so ähnlich sind, dass du sie wahrscheinlich identisch gemeint hast. (Bemerkt? Einer der Hauptvorteile von stylelint, das auf PostCSS aufbaut, ist: Mit sehr wenig Aufwand *kann stylelint Regeln einführen, die andere analytische PostCSS-Plugins verwenden*.)

#2) Best Practices erzwingen

Wenn du eine systematische Methodik in deinen Stylesheets verwendest oder eine Styleguide für deinen Code hast, solltest du in der Lage sein, bestimmte Muster entscheidend zu verbannen. stylelint bietet die Mittel dafür.

Vor allem musst du deine Selektoren kontrollieren. Schonungslos. Mit stylelint kannst du Selektoren verbieten, die eine bestimmte Spezifität überschreiten, oder die Verschachtelungstiefe begrenzen. Du kannst Selektorkategorien verbieten (z.B. keine ID-Selektoren) und reguläre Ausdrücke bereitstellen, um Namenskonventionen für den Rest durchzusetzen.

Du kannst die Verwendung von `!important` oder Browser-Hacks, die auf die von dir unterstützten Browser nicht zutreffen, blockieren. Wenn du Autoprefixer verwendest (was du wahrscheinlich solltest), kannst du die Verwendung von Vendor-Präfixen in deinen Quell-Stylesheets verbieten.

Wenn du wirklich ernsthaft werden möchtest – einige zusätzliche Zeit in die Konfiguration investieren, um absolute Konsistenz zu gewährleisten – kannst du die Reihenfolge der Eigenschaften in deinen Regeln erzwingen und Blacklists und Whitelists für Eigenschaften, Werte, Funktionen und Einheiten bereitstellen.

#3) Code-Stil-Konventionen erzwingen

stylelint verfügt über eine Vielzahl von Regeln, die Code-Stil-Konventionen automatisch durchsetzen, sodass du und deine Teammitglieder das nicht tun müssen. Wir haben versucht, diese Regeln extrem *umfassend* und extrem *flexibel* zu gestalten.

Diese Regeln betreffen hauptsächlich Leerzeichen, zielen aber auch auf andere Details wie Anführungszeichen, Groß-/Kleinschreibung, führende Nullen bei gebrochenen Zahlen, die Verwendung von Schlüsselwörtern im Vergleich zur Ausschreibung von Werten usw. ab.

Der Traum ist, dass du und deine Teammitglieder eine Formatierungskonvention *einmal* festlegen können (z. B. „Lassen wir nach dem Doppelpunkt einer Deklaration immer ein Leerzeichen!“), diese in die stylelint-Konfiguration kodifizieren und dann nie wieder darüber sprechen. Überlassen Sie die Durchsetzung der Maschinen-Empires.

#4) Alles anpassen und erweitern

Nicholas Zakas, der Erfinder von ESLint (und auch CSS Lint), hat geschrieben, dass der Schlüssel zum Erfolg von ESLint seine Erweiterbarkeit ist. stylelint versucht, dem Beispiel von ESLint zu folgen und CSS-Autoren einen Linter zu bieten, der so erweiterbar wie möglich ist.

Du kannst deine eigenen Regeln als Plugins schreiben und veröffentlichen. Es gibt bereits eine ganze Reihe; und wir sind gespannt, was andere Leute sich noch einfallen lassen.

Konfigurationen sind erweiterbar und daher teilbar. Wie bei Plugins haben wir von ESLint den Wert dieser Funktion gelernt. Schauen Sie sich an, was bereits veröffentlicht wurde, darunter Konfigurationen von WordPress und SUITCSS.

Wenn dir die integrierten Reporter von stylelint nicht gefallen, kannst du eigene erstellen, sogar einen für deine Organisation maßschneidern. Du kannst auch die Warnmeldungen anpassen, die Regeln ausgeben.

Mithilfe der API von stylelint kannst du Plugins für Texteditoren und Task-Runner erstellen, die stylelint in jeden Aspekt deines Workflows integrieren.

Und wenn dir noch andere Wege einfallen, wie du stylelint erweitern möchtest, lass es uns wissen!

Antworten auf erwartete Fragen

Wahrscheinlich schwirren ein paar Fragen in den trüben Gewässern deines Geistes. Hier sind Antworten auf die häufigsten Fragen, die uns gestellt werden

Kann ich stylelint mit SCSS? Oder Less? verwenden?

Ja, du kannst stylelint mit SCSS verwenden! Und Less-Unterstützung ist gerade angekommen! Da PostCSS benutzerdefinierte Parsers zulässt, hat stylelint keine Probleme, verschiedene nicht standardmäßige Syntaxen zu unterstützen – alles, wofür du einen PostCSS-Parser schreiben kannst.

Derzeit gibt es PostCSS-Parser – und damit stylelint-Unterstützung – für SCSS, Less und das neue SugarSS. Wenn du eine andere benutzerdefinierte Syntax sofort unterstützt haben möchtest, hilf mit, indem du am PostCSS-Parser arbeitest!

Natürlich können bestimmte Regeln bei bestimmten Aspekten deiner nicht standardmäßigen Syntax stolpern (z.B. Sass-Interpolation `#{$interpolation}` mit ID-Selektoren verwechseln). Da stylelint versucht, die fragmentierte Landschaft unserer Stylesheets abzudecken – wo einige Leute Standard-CSS verwenden, einige eine Erweiterungssprache wie SCSS, einige seltsame benutzerdefinierte Eigenschaften usw. – wird es immer Lücken zu füllen geben. Aber wir haben diese Fehler behoben, sobald wir sie gefunden haben; und in der Zwischenzeit kann jede Regel vollständig deaktiviert oder auf einer Stylesheet-für-Stylesheet- oder Zeilen-für-Zeilen-Basis deaktiviert werden.

Kann ich stylelint mit zukünftiger CSS-Syntax verwenden?

Ja! Eigentlich dieselbe Antwort wie oben: stylelint kann alles verstehen, was PostCSS versteht, was definitiv die zukünftige CSS-Syntax einschließt, die du aktivierst (wahrscheinlich über PostCSS-Plugins). Tatsächlich zielen einige der Regeln von stylelint speziell auf zukünftiges CSS wie Range-Features und benutzerdefinierte Eigenschaften ab.

Eine stylelint-Konfiguration kann riesig sein. Wo soll ich anfangen?

Wir empfehlen, Ihre Konfiguration auf eine von drei Arten zu erstellen

• Erweiterung einer veröffentlichten Konfiguration. Wir pflegen stylelint-config-standard, um eine solide Basis für die meisten Benutzer zu bieten. Und viele andere Konfigurationen wurden bereits veröffentlicht.
• Von Grund auf neu beginnen und eine Regel nach der anderen hinzufügen. Standardmäßig sind keine Regeln aktiviert, sodass du durch das Hinzufügen jeder Regel selbst genau weißt, was durchgesetzt wird, und jedes Mal, wenn du sie hinzufügst und konfigurierst, ein Verständnis für jede Regel entwickelst.
• Kopieren und Einfügen von dieser Starter-Konfiguration und Entscheiden, welche Optionen verwendet und welche Regeln gelöscht werden sollen.

Glücklicherweise musst du keine riesigen stylelint-Konfigurationen immer wieder schreiben. Erstelle eine, die deinen Vorlieben entspricht, und verwende sie überall, wo es möglich ist.

Was ist der einfachste Weg, stylelint auszuführen?

Der einfachste und beste Weg für die meisten Leute, stylelint auszuführen, ist über die CLI.

Wenn du ein Gulp-Plugin bevorzugst, probiere gulp-stylelint. Für Webpack gibt es ein paar Möglichkeiten. Wir hoffen, dass diese Plugins Leute dazu inspirieren werden, stylelint-Plugins für andere Task-Runner wie Grunt zu entwickeln. (Einfache Open-Source-Gelegenheit, wenn du eine suchst!)

Du kannst stylelint auch als PostCSS-Plugin ausführen und es in die Plugin-Kette jedes PostCSS-Runners einbinden. Das bedeutet, dass *du stylelint überall verwenden kannst, wo du PostCSS verwenden kannst* – was so ziemlich jedes Kompilierungstool da draußen abdeckt!

Außerdem gibt es bereits stylelint-Texteditor-Plugins für Atom, Sublime Text und VS Code – die schnellstmögliche Rückmeldung während deiner Arbeit geben. Für diese und weitere Tools schau dir die Liste der Complementary Tools auf der Website von stylelint an.

Hier ist, was du in der Kommandozeile erwarten kannst

Und hier ist, wie es in Atom aussieht

Wird stylelint meine Fehler beheben?

Nein, aber ein anderes Projekt namens stylefmt zielt darauf ab, genau das zu tun. Es nimmt eine stylelint-Konfiguration – dieselbe, die du zum Linting verwendest – und *korrigiert* alle Fehler, die es kann. Wir hoffen, dass stylefmt mit Community-Beiträgen so wachsen wird, dass es so viele stylelint-Regelverletzungen automatisch beheben kann, wie nur möglich. Hilf ihnen dabei!

Update: stylelint hat jetzt ein `--fix`-Flag zur automatischen Fehlerkorrektur.

Du könntest auch andere Tools wie perfectionist parallel zu stylelint verwenden, um zu beheben, was du kannst, und den Rest automatisch zu erzwingen.

Disziplin durch Linting ergänzen

Es steckt außergewöhnlich viel *Disziplin* in gutem CSS. Deshalb reden wir so viel über Methodologien wie SMACSS, ACSS, BEM, SUITCSS, ITCSS und so weiter. Wir alle wissen, dass es sehr einfach ist, CSS sehr schlecht zu schreiben. Daher müssen wir in unserer eigenen Arbeit eine intelligente Strategie entwickeln und uns eisern daran halten, wenn wir Stylesheets schreiben wollen, die uns nächste Woche nicht zum Schämen bringen.

Das ehrgeizige Ziel von stylelint ist es, unsere Disziplin durch automatische Durchsetzung zu ergänzen – einen Kernsatz von Regeln und ein erweiterbares Framework bereitzustellen, mit dem CSS-Autoren ihre eigenen Strategien durchsetzen können.

Probieren Sie es aus und lassen Sie uns wissen, wie es für Sie funktioniert. Und wenn Sie Verbesserungsideen haben, beteiligen Sie sich! Tragen Sie Regeln, Erweiterungen, Tests, Fehlerbehebungen, Dokumentation, neue Ideen oder einfach nur Feedback bei. Es gibt Arbeit für Entwickler aller Niveaus zu erledigen.