Breaking Change: meta.feature-exists()

Die Funktion meta.feature-exists() hat seit langem keine neuen Features erhalten und ist nun veraltet. Benutzer sollten andere Methoden verwenden, um festzustellen, ob ein neues Feature verfügbar ist.

Historisch gesehen verwendete Sass die Funktion meta.feature-exists() (auch verfügbar als globale Funktion feature-exists()), um Autoren zu ermöglichen, zu erkennen, ob verschiedene neue Sprachfeatures beim Kompilieren von Stylesheets verfügbar waren. Mit der Zeit hat sich jedoch herausgestellt, dass die überwiegende Mehrheit der neuen Sass-Features entweder auf geradlinigere Weise erkannt werden kann oder gar nicht sehr nützlich ist, um sie zu erkennen.

Diese Funktion ist nun veraltet und wird in Dart Sass 2.0.0 entfernt. Da Dart Sass nun die einzige offiziell unterstützte Sass-Implementierung ist und alle Versionen von Dart Sass alle von meta.feature-exists() unterstützten Features unterstützen, können alle bestehenden Verwendungen davon sicher entfernt werden.

Viele neue Features können mit meta.function-exists(), meta.mixin-exists() oder [meta.global-variable-exists()] erkannt werden. Andere können mit der Ausdruckssyntax erkannt werden, z. B. durch die Verwendung von calc(1) == 1, um festzustellen, ob die aktuelle Sass-Version First-Class- Berechnungen unterstützt.

ÜbergangszeitraumÜbergangszeitraum Permalink

Dart Sass: seit 1.78.0
LibSass: ✗
Ruby Sass: ✗

Zuerst geben wir Deprecation-Warnungen für alle Verwendungen von feature-exists aus.

In Dart Sass 2.0.0 wird meta.feature-exists() nicht mehr existieren. Versuche, sie aufzurufen, führen zu einem Fehler, und Versuche, die globale Funktion feature-exists() aufzurufen, werden als einfacher CSS-Funktionsaufruf behandelt.

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.