Wenn Sie viel CSS-Code schreiben, kann mehr als ein Fehler auftreten. Möglicherweise benötigen Sie ein Tool, um CSS-Schreibfehler zu verhindern.
Vielleicht ist Ihr Fehler manchmal wirklich ein Bug. Oder es könnte einfach eine Inkonsistenz oder ein unklarer Codierungsstil aufgrund von Schlamperei sein. Vielleicht scheinen viele davon trivial zu sein (abhängig von Ihrem Temperament), aber wenn die Codebasis wächst und mit der Zeit, werden viele Leute hässliche Dinge machen, wenn sie sie verwenden. Die Konsequenzen dieser Angelegenheit liegen außerhalb Ihrer Vorstellungskraft.
Du versuchst, dich zu kontrollieren. Auch Ihre Kollegen helfen Ihnen und korrigieren Ihre Fehler umgehend, wenn Sie unterwegs sind. Allerdings sind Sie und Ihre Kollegen die Verursacher von Fehlern, so dass ein Scheitern am Ende zumindest teilweise unvermeidlich ist. Später müssen Sie oder jemand anderes das durch den CSS-Fehler auf Ihrer Seite verursachte Problem beheben.
Weder Sie noch Ihre Kollegen diskutieren gerne über Ihre Fehler, weil sie peinlich sind. Manchmal kann es sogar frustrierend oder emotional schädlich sein. Bestimmte Disziplinen sind manchmal hilfreich bei der Aufrechterhaltung einer Codebasis, beispielsweise ein konsistenter Schreibstil, der bei manueller Implementierung etwas pedantisch und langweilig wirken kann. Andernfalls bringen sie die aufdringlichen, hartnäckigen Elemente zum Vorschein, die Sie normalerweise mögen.
Darüber hinaus möchten Sie möglicherweise Fehler rechtzeitig korrigieren können, anstatt darauf zu warten, dass jemand anderes nach der Codeüberprüfung auf den Fehler hinweist, dann die Änderung selbst vorzunehmen und zu erklären, dass Sie solche Fehler nicht noch einmal machen werden. Wenn in Ihrem CSS ein Fehler auftritt, hilft Ihnen eine rechtzeitige Rückmeldung, viel Zeit zu sparen.
Was Sie brauchen, ist eine Maschine, die Fehler verhindert
Sie benötigen eine fehlersichere Maschine, die CSS versteht und Sie versteht: Ihre Absichten, Vorlieben, Ideen und Schwächen.
Diese Maschine unterliegt Einschränkungen. Nicht alle Dinge sind perfekt. Diese Einschränkung ist jedoch für Sie und Ihre Kollegen unterschiedlich. Solange es Fehler verhindern kann, wird es sie auch weiterhin unermüdlich verhindern. In der Zwischenzeit können Sie und Ihre Kollegen die Maschine jederzeit verbessern, ihre Fähigkeiten erweitern und ihre Einschränkungen abschwächen. Es ist Open Source, und Menschen auf der ganzen Welt können mitmachen und ihren Beitrag leisten – andere Autoren, die verhindern wollen, dass sie CSS-Schreibfehler machen.
Wie alles andere brauchen auch CSS-Autoren Linters
Wir nennen diese Programme, die Fehler verhindern, „Linters“. Es gibt mehrere bessere Linters in Javascript. Insbesondere ESLint wirkt wie ein Wunder und zeigt uns, wie nützlich ein guter Linter sein kann. Aber bei CSS haben wir nicht so viel Glück und unsere Möglichkeiten sind sehr begrenzt: Ruby-basiertes scss-lint mit einem speziellen Präprozessor und das ältere CSS Lint.
Aber das war vor PostCSS. Darüber hinaus bietet PostCSS einige Methoden zum Erstellen interaktiverer CSS-Tools. Es kann jede CSS-ähnliche Syntax zur Analyse und Bedienung in ein AST-Plug-In (Abstract Syntax Tree) analysieren. Und mit benutzerdefinierten Parsern kann PostCSS sogar nicht standardmäßige ungültige Muster (z. B. //
Kommentare)
Die Bedingungen sind reif, um einen Linter mit leistungsfähigeren Funktionen zu erstellen – basierend auf der Leistung von PostCSS und inspiriert von den besten Funktionen von scss-lint und ESLint.
Ich arbeite mit mehreren Freunden an diesem Projekt und werde jetzt damit beginnen, das von uns entwickelte Tool vorzustellen: stylelint.
Dinge, die Sie mit Stylelint machen können
Das Folgende ist eine Zusammenfassung der in Stylelint ausprobierten Funktionen, das über mehr als hundert Regeln verfügt und skalierbar ist.
Wenn Sie an diesem Punkt etwas ungeduldig werden („Ok, Ok: Ich glaube, dass Stylelint Wunder bewirken wird. Keine Notwendigkeit, es zusammenzufassen.“). Fahren Sie einfach mit dem nächsten Abschnitt fort, in dem ich nur auf einige Probleme eingehen und einige Tipps geben werde.
Fehlererkennung
Einige Stylelint-Regeln dienen dazu, offensichtliche Fehler zu erkennen, z. B. Rechtschreibfehler oder Auslassungen, die Sie gemacht haben, als Sie abgelenkt waren oder trübe Augen hatten. Sie können beispielsweise leere Blöcke, ungültige Hex-Werte, doppelte Selektoren, unbenannte Animationsnamen und falsche lineare Farbverlaufssyntax unterdrücken.
Bei den anderen Regeln geht es darum, Ihr Bestes zu geben, um subtilere Fehler zu erkennen. Hier ist eine Regel: Geben Sie eine Warnung aus, wenn Sie ein Kurzattribut (wie margin-top
) verwenden, das sein Attribut-Gegenstück (wie margin
) überschreibt, da dies möglicherweise auf ein Versehen Ihrerseits zurückzuführen ist. Darüber hinaus gibt es auch eine Regel, die Sie warnt: Wenn eine verwirrende Situation auftritt, z. B. wenn Regel A vor Regel B erscheint, Regel B jedoch überschrieben wird, weil der Selektor von Regel A eine höhere Priorität hat (z. B. Regel A). .foo.bar{···}
, Regel B ist .foo{···}
). Das ist eine sehr heikle Situation.
Es gibt auch eine Regel, die das Douse-Plugin von PostCSS verwendet, um zu prüfen, ob Ihr Browser diesen Stil unterstützt. Der andere verwendet das CSS-Colorguard-Plugin, um die Ähnlichkeit von Farben anzuzeigen, um Sie nicht zu verwirren. (Bitte beachten Sie: Dies ist einer der Hauptvorteile von Stylelint gegenüber PostCSS: Stylelint kann im Vergleich zu anderen PostCSS-Plugins mit sehr geringem Aufwand Eingabeaufforderungen durchführen.)
Best Practices durchsetzen
Wenn Sie Systemmethoden in Ihren Stylesheets verwenden oder einen Styleguide für Ihren Code festlegen, sollten Sie diese Muster deaktivieren. stylelint stellt diese Funktionen bereits bereit.
Zuerst müssen Sie eine strenge Kontrolle über Ihre Selektoren haben. Mit stylelint können Sie Selektoren ab einer bestimmten Spezifität deaktivieren oder Grenzen für die Verschachtelungstiefe festlegen. Sie können Kategorieselektoren (z. B. Selektoren ohne IDs) unterdrücken und für die übrigen Selektoren Namenskonventionen für reguläre Ausdrücke verwenden.
Sie können die Verwendung von !important
oder Browser-Hacks deaktivieren, die Ihr Browser nicht unterstützt. Wenn Sie Autoprefixer verwenden (oder sollten), können Sie die Verwendung von Herstellerpräfixen in Quell-Stylesheets deaktivieren.
Wenn Sie strenger sein möchten – Sie können etwas Zeit in die Konfiguration investieren, um absolute Konsistenz sicherzustellen – können Sie die Reihenfolge der Stylesheet-Eigenschaften erzwingen und Eigenschaften, Werte für Blacklist, Whitelist und Funktionen bereitstellen, die auch Einheiten haben.
Codestilkonventionen durchsetzen
stylelint erzwingt automatisch Codestilkonventionen, sodass Sie und Ihre Teamkollegen diese nicht aktiv einrichten müssen. Wir sind bestrebt, diese Regeln umfassender und flexibler zu gestalten.
Diese Regeln konzentrieren sich hauptsächlich auf Leerzeichen, gelten aber auch für andere Details, wie Anführungszeichen, Groß- und Kleinschreibung, das Schreiben von Nullen vor Dezimalstellen, die Verwendung von Schlüsselwörtern und die Schreibweise von Werten usw.
Träumen Sie davon, dass Sie und Ihre Teamkollegen eine Formatierungskonvention festlegen (z. B. lassen wir in einer Deklaration immer ein Leerzeichen nach einem Doppelpunkt stehen) und diese in Ihrer Stylelint-Konfiguration ändern können, und Sie müssen nicht noch einmal darüber diskutieren. Lassen Sie es im Maschinenreich ausführen.
Alles machen und erweitern
Nicholas Zakas, der Schöpfer von ESLint (und CSS Lint), schreibt, dass der Erfolg von ESLint in seiner Erweiterbarkeit liegt. stylelint versucht, dem Beispiel von ESLint zu folgen und CSS-Autoren einen Linter zur Verfügung zu stellen, der auch erweiterbar ist.
Sie können Ihre eigenen Regel-Plugins schreiben und veröffentlichen. Es gibt mittlerweile eine Menge davon und wir sind gespannt, die tollen Plugins anderer Leute zu sehen.
Konfigurationen sind erweiterbar und können daher geteilt werden. Was Plug-ins betrifft, haben wir den Wert dieser Funktion von ESLint erfahren. Überprüfen Sie, welche WordPress- und SUITCSS-Konfigurationen sowie veröffentlichte Konfigurationen enthalten.
Wenn Ihnen die integrierten Hinweise von stylelint nicht gefallen, können Sie Ihre eigenen Stile manuell erstellen, sogar für Ihre Organisation. Sie können auch die Regeln anpassen, die zum Bereitstellen von Warnmeldungen verwendet werden.
Mit der Stylelint-API können Sie Text-Compiler-Plug-Ins erstellen und diese testen, um Stylelint in jeden Aspekt Ihres Workflows zu integrieren.
Wenn Sie Ideen für Stylelint-Erweiterungen haben, lassen Sie es uns bitte wissen!
Antworten auf erwartete Fragen
Möglicherweise gehen Ihnen mehrere Fragen durch den Kopf. Hier einige Erklärungen zu den häufigsten Fragen:
Ist es möglich, Stylelint in SCSS oder Less zu verwenden?
Die Antwort lautet: Ja, Sie können Stylelint in SCSS verwenden und es wird in Less unterstützt! Da PostCSS benutzerdefinierte Parser zulässt, kann stylelint problemlos eine Vielzahl nicht standardmäßiger Syntaxen unterstützen – Sie können einen PostCSS-Parser zum Parsen anpassen.
Aufgrund des PostCSS-Parsers unterstützt stylelint SCSS, Less und das neue SugarSS. Wenn Sie eine weitere benutzerdefinierte Syntaxunterstützung implementieren möchten, können Sie dies über PostLess erreichen!
Natürlich gibt es bestimmte Regeln, die Ihrer nicht standardmäßigen Syntax im Weg stehen (z. B. das #{$interpolation}
, das Sass-ID-Selektoren verwirrt). Da Stylelint versucht, den Stil unserer Stylesheets zu maskieren – manche Leute nutzen Standard-CSS, manche nutzen erweiterte Sprachen wie SCSS, manche nutzen einige seltsame benutzerdefinierte Eigenschaften usw. – entstehen dadurch unweigerlich einige Lücken, die gefüllt werden müssen. Wir arbeiten jedoch ständig an diesen Fehlern, sobald wir sie finden. In der Zwischenzeit können alle Regeln für jedes Stylesheet oder jede Zeile ganz deaktiviert werden.
Kann Stylelint zukünftige CSS-Syntax verwenden?
Ja! Ähnlich wie bei der oben angegebenen Antwort: stylelint kann alles verstehen, was PostCSS versteht, einschließlich der Aktivierung zukünftiger CSS-Syntax (möglicherweise über PostCSS-Plugins). Tatsächlich behandeln einige Stylelint-Regeln speziell die zukünftige CSS-Syntax und einige benutzerdefinierte Eigenschaften.
Die Stylelint-Konfiguration ist riesig, wo fange ich an?
Wir empfehlen drei Konfigurationsmethoden:
Eine veröffentlichte Konfiguration erweitern. Wir pflegen Stylelint-Konfigurationsstandards, um Benutzern eine konsistente Basis zu bieten. Und es wurden auch viele Konfigurationen angekündigt. Beginnen Sie bei Null und fügen Sie jeweils eine Regel hinzu. Standardmäßig ist keine der Regeln aktiviert. Wenn Sie also Regeln manuell hinzufügen, wissen Sie, welche durchgesetzt werden, und können jede von Ihnen hinzugefügte Regel verstehen. Aktivieren Sie die Konfiguration zum Kopieren und Einfügen, entscheiden Sie, welche Optionen verwendet werden sollen, und entfernen Sie diese gezielt.
Zum Glück müssen Sie nicht immer wieder riesige Stylelint-Konfigurationen schreiben. Sie können einen Stil auswählen, der Ihnen gefällt, und ihn überall verwenden.
Der einfachste Weg, stylelint auszuführen?
Für die meisten Menschen ist der einfachste Weg die Befehlszeile.
Wenn Sie das Gulp-Plugin bevorzugen, können Sie gulp-stylelint verwenden. Wenn es um Webpack geht, stehen viele Optionen zur Auswahl. Wir hoffen, dass diese Plugins Sie dazu inspirieren, weitere Stylelint-Plugins zu erstellen, beispielsweise für Grunt. (Sie finden es in Open-Source-Projekten!)
Sie können stylelint auch mit dem PostCSS-Plugin ausführen, einschließlich aller im Plugin enthaltenen Elemente. Das bedeutet, dass Sie stylelint überall dort verwenden können, wo Sie PostCSS verwenden können (das fast jedes Kompilierungstool abdeckt)!
Darüber hinaus gibt es auch ein Stylelint-Textkompilierungs-Plug-in für Atom, Sublime Text und VS Code, um schnellstes Feedback zu liefern. Weitere Informationen finden Sie in der Liste der ergänzenden Tools auf der Stylelint-Website.
Wie unten gezeigt, werden in der Befehlszeile die erwarteten Ergebnisse angezeigt:
wird in Atom wie folgt angezeigt:
Kann Stylelint meinen Fehler beheben?
Nein, aber ein anderes namens stylefmt zielt genau darauf ab. Es erfordert eine Stylelint-Konfiguration – sehr ähnlich der, die Sie für Linting verwenden – und kann alle Fehler beheben. Wir hoffen, dass stylelint mit Beiträgen der Community weiterentwickelt werden kann, um Fehler, die gegen die Stylelint-Regeln verstoßen, automatisch zu beheben. Bitte helfen Sie ihnen, dieses Ziel zu erreichen!
Sie können auch andere Tools wie CSScomb oder Perfectionlist in Kombination mit Stylelint verwenden, um Unterbrechungen automatisch zu beheben und zu erzwingen.
Verwenden Sie Flusen zur Ergänzung der Zwänge
Gutes CSS unterliegt einer Vielzahl von Einschränkungen. Aus diesem Grund verbringen wir viel Zeit damit, Methoden wie SMACSS, ACSS, BEM, SUITCSS, ITCSS usw. zu diskutieren. Wir alle wissen, wie einfach es ist, schlechtes CSS zu schreiben. Wenn wir also keine Angst mehr davor haben, CSS-Stile zu schreiben, müssen wir in unserer Arbeit eine intelligente Strategie etablieren und mutig daran festhalten.
Das Ziel von stylelint ist die Automatisierung der Ausführung – die Bereitstellung eines Kernregelsatzes und eines steckbaren Frameworks, mit dem CSS-Autoren ihre eigenen Strategien implementieren können.
Probieren Sie es aus und lassen Sie uns wissen, wie es für Sie funktioniert. Wenn Sie Ideen für bessere Verbesserungen haben, wie zum Beispiel Beitragsregeln, Verbesserungen, Tests, Fehlerbehebungen, Dokumentation, neue Ideen oder einfach nur Feedback, schreiben Sie uns bitte eine Nachricht! Das gibt unseren Entwicklern auf allen Ebenen etwas zu tun.