Unsere Erfahrung beim Wechsel von weniger zu Sass

Es wurde viel über den Wechsel von Vanilla-CSS zu einem CSS-Präprozessor geschrieben, und das aus gutem Grund: Präprozessoren erhöhen die Leistung und Kontrolle, die wir im Browser allein nicht erreichen können. Aus Artikeln, die preisen die Tugenden eines Präprozessors zu technischeren Lektüren wie Etsys detailliertem „ Übergang zu SCSS im Maßstab 'Ich habe das Gefühl, ich habe sie alle verschlungen.

Beim HASHTAGS haben wir etwas gemacht, über das nicht annähernd so viel geschrieben wurde - von einem Präprozessor zu einem anderen zu wechseln. Schon früh adoptierte Sprout Weniger ;; Wir haben Ende letzten Jahres die Entscheidung getroffen, auf SCSS umzusteigen, die CSS-ähnliche Syntax von Sass . Wir haben uns Zeit genommen, um sicherzustellen, dass der Übergang reibungslos verlief, und die Erfahrung hat einige tiefe Unterschiede zwischen Less und Sass aufgezeigt.

Warum?

Bevor wir zu dem kommen, was wir gelernt haben, sollte Ihre erste Frage - eine legitime - lauten: 'Warum sich die Mühe machen?' Wir haben bereits von Variablen und Mixins, @ Importen und Farbfunktionen profitiert. Sicherlich hat Sass eine Reihe von Funktionen, die weniger fehlen, wie z Karten und Funktionen , aber wir haben es so weit ohne sie geschafft.

Zwei Hauptgründe für den Wechsel sind hervorzuheben:

1. Gemeinschaft: Suchen Sie in github nach lib extension: scss und dann nach lib extension: less. Zum jetzigen Zeitpunkt sind die Ergebnisse klar: 120.234 SCSS-Dateien, 29.449 weniger Dateien. Das Wechseln bietet Zugang zu einer größeren Auswahl an guten Ideen und einem größeren Open-Source-Pool zum Schwimmen. Sogar die beliebte Bootstrap-Bibliothek, einer der Gründe, warum Less funktionsfähig geblieben ist, hat angekündigt es wechselt zu SCSS .
2. Geschwindigkeit: Libsass Felsen. Die Bauzeit für unsere Stile hat sich um über 500% verbessert. Obwohl Libsass die neueste Version der Sass-Spezifikation noch nicht eingeholt hat, haben wir nicht das Gefühl, dass uns etwas fehlt.

Wie?

Unser kompiliertes CSS hat fast 19.000 Selektoren. Nach dem Wechsel musste das kompilierte CSS nahezu identisch sein. Wir mussten sicherstellen, dass dieser Übergang für unsere Kunden unsichtbar war. Und was ist mit den derzeit laufenden Funktionen? Unser aktuelles Compose-Update 3.837 Stillinien geändert - wie konnte dieses Team sicher den Midstream wechseln?

Wir haben drei Optionen in Betracht gezogen:

1. Kompilieren Sie zuerst alles in CSS. Dies ist die einzige Möglichkeit, mit 100% iger Genauigkeit sicherzustellen, dass unsere Benutzer dieselben Stile erhalten, und den Schalter tatsächlich an einem Tag zu betätigen. Die Idee einer sauberen Pause ist immer verlockend, aber Neuer Code ist nicht immer besserer Code . Auch mit Werkzeugen wie sass-konvertieren und css2compass Die Zeit, die wir für den Wiederaufbau aufwenden würden, würde alle anderen Optionen bei weitem überwiegen.
2. Schreiben Sie nur neue Stile in SCSS. Wir überlegten, eine Linie in den Sand zu ziehen - Weniger ist alt und kaputt; Sass ist die neue Schärfe . Letztendlich haben wir diesen Gedanken abgelehnt. Durch den sofortigen Wechsel würde so viel gewonnen, und niemand wollte die Parität zwischen zwei Sätzen von Mixins und Variablen aufrechterhalten.
3. Konvertieren Sie alle unsere Less-Dateien in SCSS und beheben Sie die Fehler. Da wir entweder den Verlauf wegwerfen oder eine weitere Build-Aufgabe hinzufügen müssen, um sie zu verwalten, haben wir uns daran gemacht, alles zu konvertieren.

Das Haus putzen

SCSS unterscheidet sich nicht so sehr von Less, oder? „ Konvertieren von Less zu Sass ”Teilt eine Reihe von Regex-Suchen, um die offensichtlichsten Syntaxunterschiede zu ändern, z. B. .awesome-mixin () vs @mixin awesome-mixin (). Diese Regex-Suchen werden in zusammengefasst less2sass , die wir alle unsere Dateien durchlaufen haben.

Wenn es so einfach wäre, gäbe es wirklich nicht viel zu bloggen. Ein paar anhaltende Pull-Anfragen an das less2sass-Skript betonen einige seiner Versehen, wie z Zeichenfolgeninterpolationsunterschiede . Schwieriger waren die Build-Fehler, die nach der Konvertierung aufgetreten sind und die Unterschiede hervorhoben, die größer waren, als ein einfacher regulärer Ausdruck beheben konnte. Um ehrlich zu sein, haben wir auch schlechtes CSS gefunden.

Wir haben diese Build-Fehler genommen und eine Liste der zu behebenden Fehler erstellt. Wir wussten, dass wir das meiste davon beheben können, bevor wir die Stile konvertieren. Wir haben uns entschlossen, unsere Less-Dateien vor der Konvertierung zu bereinigen.

Fixin ’Mixins

Wir haben mit dem Unterschied begonnen, wie Less und Sass mit Bedingungen umgehen. Hier ist eine einfache Gradientenmischung, die wir hatten:

Sass bietet eine einfache @ if… @ else-Struktur, während unser Mixin das verwendet, was Less a nennt Mixin Guard . Im Fall unseres Gradienten-Mixins haben wir es verwendet, um von der vom Hersteller vorangestellten Entwurfssyntax zur W3C-Syntax zu wechseln. Wir wussten, dass wir dieses Mixin neu schreiben müssen.

Dann hielten wir an und sahen uns alle unsere Mixins genauer an. Die meisten von ihnen fügten Herstellerpräfixe hinzu und lösten Browserunterschiede wie das obige Gradientenmixin. Eingeben Autoprefixer , ein Tool, das CSS analysiert und Herstellerpräfixe basierend auf einer Liste unterstützter Browser anwendet. Durch Hinzufügen von Autoprefixer zu unserem Build haben wir neun Mixins eliminiert. Als Bonus entfernt Autoprefixer nicht benötigte Herstellerpräfixe, wodurch wir einige staubige Ecken in unserem CSS identifizieren und kleinere kompilierte Dateien erstellen konnten.

Eine gute Lektion aus unserer Erfahrung hier: Verschwenden Sie keine Zeit damit, zu konvertieren oder umzugestalten, was Sie löschen können.

Ein weiterer bemerkenswerter Mixin-Unterschied: Less empfiehlt, Parameter durch Semikolons zu trennen . Nur wenige waren auf diese Weise geschrieben worden, aber sie mussten alle geändert werden, in den Mixin-Definitionen und wo sie angewendet wurden. Glücklicherweise unterstützt Less sowohl Semikolons als auch Kommas, sodass wir diese Änderung vor dem Konvertierungsschritt vornehmen können.

---

Nummer 22 sehen

---

Kaufmännisches Und-Missbrauch

Nachdem wir uns mit Mixins befasst hatten, wandten wir uns einer anderen Quelle von Buildfehlern zu: kaufmännisches Und . Es ist einer der leistungsstärksten Operatoren in Sass und Less und sie arbeiten sehr ähnlich. Außer wenn sie es nicht tun. Und dann arbeiten sie ganz anders.

Bei 19.000 Selektoren können Sie sich beispielsweise vorstellen, dass wir auf Spezifitätsprobleme stoßen, die häufig schnell als solche gelöst werden:

Weniger produziert h1.modal-Header, wie man vermuten würde, aber Sass erstickt. Wir haben versucht, das Problem zu beheben mit:

Funktioniert hervorragend mit Ruby Sass, aber zum jetzigen Zeitpunkt Libsass unterstützt diese Verwendung noch nicht . In diesem Fall haben wir nicht einmal daran gedacht, zu Ruby Sass zu wechseln. Wir haben stattdessen den h1.modal-Header außerhalb des Bereichs von .modal geschrieben. Wir wissen, dass dies ein Hinweis auf ein Problem ist. Wenn Sie also den Selektor aus dem Bereich ziehen und ihn mit einem Kommentar aufrufen, können Sie diese Probleme in unserem Code leichter identifizieren.

Es wurde schlimmer, wenn ein kaufmännisches Und auf diese Weise in einem Mixin verwendet wurde. Hier ist ein Auszug aus einem weniger Mixin, das wir für Buttons hatten:

Auch hier konnte uns die @ at-root-Direktive in Libsass nicht helfen. In diesem Fall mussten wir die Grundursache für die Überschreibung der Spezifität untersuchen und beheben. (Die gute Nachricht ist, dass wir das Problem behoben haben, indem wir drei übermäßig spezifische Stile an anderer Stelle gelöscht haben.)

Ein weiterer Unterschied zwischen dem kaufmännischen Und von Less und Sass war tatsächlich hilfreich:

Unsere Erwartung war .checkbox-wrap> .checkbox-widget, .radio-wrap> .radio-widget. Less verarbeitet das kaufmännische Und jedoch mit mehr Rekursion und kompiliert folgendermaßen:

Zu keinem Zeitpunkt haben wir - oder würden wir - ein Kontrollkästchen-Widget für ein Optionsfeld verwendet. Glücklicherweise hat Sass tatsächlich ein Problem gelöst, von dem wir nichts wussten, weil wir uns unser kompiliertes CSS nicht angesehen haben.

Lektion gelernt: Sehen Sie sich Ihr kompiliertes CSS häufig an. Andernfalls wissen Sie nicht, was Ihre Benutzer herunterladen.

Vergleich der Ergebnisse

Die Aktualisierungen zum Beheben und Entfernen von Mixins, zum Beheben von kaufmännischen Und-Abweichungen und zum Beheben einiger anderer Bits, die nicht sauber konvertiert werden konnten, erfolgten im Laufe eines Monats über sieben Commits hinweg. Es fühlte sich gut an, das Haus zu putzen und zukünftige Refactoring-Möglichkeiten zu identifizieren.

Es spielt jedoch keine Rolle, wie unser Quellcode aussieht. Es kommt darauf an, was an unsere Benutzer geliefert wird. Wir haben darüber nachgedacht zu generieren ASTs um unser kompiliertes CSS zu vergleichen. Nach einigen Recherchen und Experimenten wurde klar, dass wir nur wissen mussten, ob sich am kompilierten CSS nur sehr wenig geändert hatte. Daher würden gute altmodische Unterschiede ausreichen - je kleiner der Unterschied, desto besser. Jede Pull-Anfrage enthielt einen Unterschied zu den Vorher-Nachher-Ergebnissen der Less-Kompilierung. Das Xcode-Entwicklertool FileMerge war sehr praktisch, um die Ergebnisse nebeneinander zu vergleichen. Wenn wir etwas sahen, was wir nicht erwartet hatten, gingen wir zurück, um nachzuforschen.

Wir haben uns an FileMerge und diffs gehalten, als wir unsere Regex-Stampede zum Suchen und Ersetzen von Regex gestartet und die Dateien tatsächlich in SCSS konvertiert haben. Die Ergebnisse, die von zwei verschiedenen Präprozessoren zusammengestellt wurden, machten unsere Unterschiede jedoch aufgrund unterschiedlicher Tabulatoren und Klammerplatzierungen unbrauchbar. Wir haben einen zusätzlichen Schritt hinzugefügt, um das Format des Vorher-Nachher-CSS mit zu normalisieren ein einfaches Knotenskript . Es minimiert das CSS und verschönert es dann. Einfacher geht es nicht.

Das Normalisieren der Formatierung hat sehr geholfen, aber das Durchkämmen des Diff dauerte noch etwa zwei Tage. Ein lohnender Prozess, aber mühsam. Wir bezweifeln, dass eine benutzerdefinierte AST-Lösung dazu beigetragen hätte, die Überprüfung zu beschleunigen. Alle Unterschiede mussten angegangen werden.

Die Unterschiede waren jedoch gering. Selektoren in einer etwas anderen Reihenfolge, Dezimalrundung und sogar geringfügige Unterschiede in den Ergebnissen der Farbfunktionen. Jeder Unterschied wurde sorgfältig geprüft, bevor unser Sassed-up CSS in Produktion ging.

Was kommt als nächstes

Nach dem Zusammenschluss kam die laufende Arbeit kaum zum Stillstand. Weniger Dateien, die sich noch in der Entwicklung befinden, konnten dank aller Vorbereitungsarbeiten einfach konvertiert werden. Alle waren in ungefähr zwei Tagen einsatzbereit. Sogar das neu gestaltete Compose-Team konnte sich innerhalb weniger Stunden auf den Weg zu SCSS machen. Vorausplanen und Bereinigen vorhandener Stile vor dem Drücken des Schalters machten den Unterschied.

Jetzt identifizieren wir Muster, teilen große CSS-Dateien in Module auf, prüfen CSS in der Produktion auf nicht verwendete Selektoren und verbringen mehr Zeit mit Tools zum Vergleichen von ASTs oder einer anderen analysierten Darstellung unseres CSS. Habe ich schon erwähnt, dass wir fast 19.000 CSS-Selektoren haben? Wir sind dabei - aber das ist ein ganz anderer Artikel.

Teile Mit Deinen Freunden: