Breaking Change: Gemischte Deklarationen
CSS ändert seine Handhabung von Deklarationen, die mit verschachtelten Regeln gemischt sind, und wir möchten sicherstellen, dass Sass diesem Verhalten entspricht.
Die bisherige EntwicklungDie bisherige Entwicklung Permalink
Historisch gesehen zog Sass, wenn Sie verschachtelte Regeln und Deklarationen mischten, alle Deklarationen an den Anfang der Regel, um den äußeren Selektor nicht unnötig zu duplizieren. Zum Beispiel
CSS-Ausgabe
.example {
color: red;
font-weight: normal;
}
.example a {
font-weight: bold;
}
Als Plain CSS Nesting zuerst eingeführt wurde, verhielt es sich genauso. Nach reiflicher Überlegung entschied die CSS Arbeitsgruppe jedoch, dass es sinnvoller sei, die Deklarationen in der Reihenfolge anzuwenden, in der sie im Dokument erscheinen, wie hier
CSS-Ausgabe
.example {
color: red;
}
.example a {
font-weight: bold;
}
.example {
font-weight: normal;
}
Ausmusterung des alten VerfahrensAusmusterung des alten Verfahrens Permalink
- Dart Sass
- seit 1.77.7
- LibSass
- ✗
- Ruby Sass
- ✗
Die Verwendung von Deklarationen *nach* verschachtelten Regeln wird in Sass derzeit als veraltet markiert, um Benutzer auf die bevorstehende Änderung aufmerksam zu machen und ihnen Zeit zu geben, ihre Stylesheets damit kompatibel zu machen. In einer zukünftigen Version wird Dart Sass geändert, um die Reihenfolge des Plain CSS Nesting zu übernehmen.
Wenn Sie die neuen CSS-Semantiken frühzeitig nutzen möchten, können Sie Ihre verschachtelten Deklarationen in & {} einschließen
CSS-Ausgabe
.example {
color: red;
}
.example a {
font-weight: bold;
}
.example {
font-weight: normal;
}
Kann ich die Warnungen unterdrücken?
Sass bietet eine leistungsstarke Reihe von Optionen zur Verwaltung, welche Deprecations-Warnungen Sie wann sehen.
Terse- und Verbose-Modus
Standardmäßig läuft Sass im Terse-Modus, in dem jede Art von Deprecations-Warnung nur fünfmal ausgegeben wird, bevor weitere Warnungen unterdrückt werden. Dies stellt sicher, dass die Benutzer wissen, wann sie sich einer bevorstehenden Breaking Change bewusst sein müssen, ohne eine überwältigende Menge an Konsolenrauschen zu erzeugen.
Wenn Sie stattdessen Sass im Verbose-Modus ausführen, wird jede Deprecations-Warnung ausgegeben. Dies kann nützlich sein, um die verbleibende Arbeit bei der Behebung von Deprecations zu verfolgen. Sie können den Verbose-Modus mit dem Flag --verbose in der Befehlszeile oder der Option verbose in der JavaScript API aktivieren.
⚠️ Vorsicht!
Wenn Sass über die JS API ausgeführt wird, teilt Sass keine Informationen über Kompilierungen hinweg. Daher werden standardmäßig fünf Warnungen für *jedes kompilierte Stylesheet* ausgegeben. Sie können dies jedoch beheben, indem Sie einen benutzerdefinierten Logger schreiben (oder den Autor Ihres bevorzugten Frameworks dazu auffordern, dies zu tun), der nur fünf Fehler pro Deprecation ausgibt und über mehrere Kompilierungen hinweg geteilt werden kann.
Deprecations in Abhängigkeiten unterdrücken
Manchmal haben Ihre Abhängigkeiten Deprecations-Warnungen, auf die Sie keinen Einfluss haben. Sie können Deprecations-Warnungen von Abhängigkeiten unterdrücken, während sie für Ihre Anwendung weiterhin ausgegeben werden, indem Sie das Flag --quiet-deps in der Befehlszeile oder die Option quietDeps in der JavaScript API verwenden.
Für die Zwecke dieses Flags ist eine "Abhängigkeit" jedes Stylesheet, das keine reine Serie relativer Ladevorgänge vom Einstiegs-Stylesheet ist. Das bedeutet alles, was von einem Lade-Pfad kommt, und die meisten Stylesheets, die über benutzerdefinierte Importer geladen werden.
Spezifische Deprecations unterdrücken
Wenn Sie wissen, dass eine bestimmte Deprecation für Sie kein Problem darstellt, können Sie Warnungen für diese spezifische Deprecation unterdrücken, indem Sie das Flag --silence-deprecation in der Befehlszeile oder die Option silenceDeprecations in der JavaScript API verwenden.