Breaking Change: Ungültige Kombinatoren

Sass war historisch gesehen sehr nachsichtig bei der Verwendung von führenden, nachgestellten und wiederholten Kombinatoren in Selektoren. Diese Kombinatoren werden außer dort, wo sie für Nesting nützlich sind, deprecared.

Sass hat historisch drei ungültige Verwendungen von Kombinatoren unterstützt

  • Führende Kombinatoren, wie in + .error {color: red}.

  • Nachgestellte Kombinatoren, wie in .error + {color: red}.

  • Wiederholte Kombinatoren, wie in div > > .error {color: red}.

Keine dieser ist gültiges CSS, und alle führen dazu, dass Browser die betreffende Stilregel ignorieren. Ihre Unterstützung erhöhte die Komplexität der Sass-Implementierung erheblich und machte es besonders schwierig, verschiedene Fehler im Zusammenhang mit der @extend-Regel zu beheben. Daher haben wir die Entscheidung getroffen, die Unterstützung für diese Verwendungen zu entfernen.

Es gibt eine wichtige Ausnahme: führende und nachgestellte Kombinatoren dürfen weiterhin für Nesting-Zwecke verwendet werden. Zum Beispiel wird Folgendes noch sehr stark unterstützt

Spielplatz

SCSS-Syntax

.sidebar > {
  .error {
    color: red;
  }
}
Spielplatz

Sass-Syntax

.sidebar >
  .error
    color: red

CSS-Ausgabe

.sidebar > .error {
  color: red;
}

Sass wird nur dann einen Fehler ausgeben, wenn ein Selektor nach der Auflösung des Nestings immer noch einen führenden oder nachgestellten Kombinator hat. Wiederholte Kombinatoren hingegen werden immer Fehler sein.

Um sicherzustellen, dass bestehende Stylesheets, die (wahrscheinlich versehentlich) ungültige Kombinatoren enthalten, unterstützen wir eine Übergangszeit bis zur nächsten Hauptversion von Dart Sass.

ÜbergangszeitraumÜbergangszeitraum Permalink

Kompatibilität
Dart Sass
seit 1.54.0
LibSass
✗
Ruby Sass
✗

Zunächst geben wir Deprecation-Warnungen für alle doppelten Kombinatoren sowie für führende oder nachgestellte Kombinatoren aus, die nach der Auflösung des Nestings in Selektoren landen .

💡 Lustige Tatsache

Denken Sie daran, dass Sie Deprecation-Warnungen von Bibliotheken, die Sie nicht kontrollieren, unterdrücken können! Wenn Sie die Befehlszeilenschnittstelle verwenden, können Sie das Flag --quiet-deps übergeben, und wenn Sie die JavaScriptAPI verwenden, können Sie die Option quietDeps auf true setzen.

Darüber hinaus beginnen wir sofort damit, Selektoren, von denen wir wissen, dass sie ungültiges CSS sind, aus dem kompilierten CSS wegzulassen, mit einer Ausnahme: Wir lassen Selektoren, die mit einem führenden Kombinator beginnen, nicht weg, da sie aus einer verschachtelten @import-Regel oder dem meta.load-css()-Mixin verwendet werden können. Wir empfehlen dieses Muster jedoch nicht und werden die Unterstützung dafür in Dart Sass 2.0.0 einstellen.

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.