Vue CLI CSS-Vorprozessoroption: Dart-Sass VS Node-Sass?

Beim Erstellen eines neuen Projekts mit CLI (v3.7.0) können Sie zwischen einem dart-sassoder einem node-sassCompiler wählen .

Wie vergleichen sich diese miteinander, um genauer zu sein als in Vue-Dokumenten angegeben ?

Ein Tipp zur Sass-Leistung

Beachten Sie, dass bei Verwendung von Dart Sass die synchrone Kompilierung aufgrund des Overheads asynchroner Rückrufe standardmäßig doppelt so schnell ist wie die asynchrone Kompilierung. Um diesen Overhead zu vermeiden, können Sie das Glasfaserpaket verwenden, um asynchrone Importeure aus dem synchronen Codepfad aufzurufen. Um dies zu ermöglichen, installieren Sie einfach Fasern als Projektabhängigkeit:

npm install -D fibers

Da es sich um ein natives Modul handelt, können Kompatibilitätsprobleme je nach Betriebssystem und Build-Umgebung auftreten. In diesem Fall führen Sie bitte aus npm uninstall -D fibers, um das Problem zu beheben.

? Pick a CSS pre-processor (PostCSS, Autoprefixer and CSS Modules are supported by default): (Use arrow keys)
❯ Sass/SCSS (with dart-sass)
  Sass/SCSS (with node-sass)
  Less
  Stylus

EDIT 2020/01: Vue CLI 4.2.2 neues Projekt erstellen schlägt noch dart-sassals erste Option vor node-sass. Hier wurde jedoch festgestellt, dass dies node-sassdie performantere Wahl ist, und fast niemand verwendet Dart-Sass (Kommentar von Ccleve).

EDIT 2020/09: Da Ali Bahrami seine ausführliche Antwort aktualisiert hat, dart-sassist dies die bevorzugte Wahl, da node-sasssie als veraltet markiert wird .

Schade, dass dart-sasses sich um eine JS-kompilierte Version handelt, die eine schlechte Leistung aufweist. Die Entwickler sind sich dessen jedoch bewusst und arbeiten auf eine höhere Leistung hin, wie in dieser Ausgabe angegeben .

Update 17.09.2020 :

Da diese Antwort jeden Tag positiv bewertet wird, dachte ich, dass es sich lohnt, tiefer in dieses Thema einzutauchen.

Betrachtet man die sass-lang-Website :

Dart Sass ist die primäre Implementierung von Sass, was bedeutet, dass es vor jeder anderen Implementierung neue Funktionen erhält. Es ist schnell, einfach zu installieren und wird zu reinem JavaScript kompiliert , was die Integration in moderne Webentwicklungs-Workflows erleichtert.

Dart-Sass ist schnell, aber nicht die JS-kompilierte Version . Wenn wir Dart-Sass sagen, gibt es praktisch zwei Möglichkeiten:

• Dart-Sass auf Dart-VM
• Dart-Sass auf NPM , einer reinen JS-kompilierten Version

Ich habe die Bootstrap 4 Sass-Datei mit Node-Sass, Dart-Sass und Dart-Sass (JS) zu CSS kompiliert und Sie können das folgende Ergebnis sehen:

• In diesem speziellen Fall sind zwei Sekunden keine große Sache; Bedenken Sie jedoch, dass Dart-Sass (JS) neunmal langsamer als Dart-Sass (Dart VM) und dreimal langsamer als Node-Sass ist.
• Ich hatte ein Projekt mit +20 Themen, es dauerte 30 Sekunden mit Node-Sass, aber ich habe versucht, Dart-Sass (JS) zu verwenden, und es hat ein Jahrhundert gedauert!
• Obwohl Dart-Sass (Dart VM) am schnellsten ist, ist die Installation oder Integration etwas schwierig.
• Und Node-Sass gilt als veraltet .

Ich habe hier darüber gebloggt , hier kannst du mehr darüber lesen.

Node-Sass ist zwar schneller als Dart-Sass, aber zum Zeitpunkt des Schreibens ist dieser Dart-Sass die einzige Bibliothek, die die @useRegel implementiert , die dringend empfohlen wird @import. Laut der offiziellen sass-lang-Website :

Was ist @importlos mit ? Die @importRegel hat eine Reihe schwerwiegender Probleme:

• @importmacht alle Variablen, Mixins und Funktionen global zugänglich. Dies macht es für Menschen (oder Werkzeuge) sehr schwierig zu sagen, wo etwas definiert ist.

• Da alles global ist, müssen Bibliotheken allen Mitgliedern ein Präfix voranstellen, um Namenskollisionen zu vermeiden.

• @extend Regeln sind auch global, was es schwierig macht vorherzusagen, welche Stilregeln erweitert werden.

• Jedes Stylesheet wird ausgeführt und sein CSS wird jedes Mal @importausgegeben, wenn es bearbeitet wird. Dies erhöht die Kompilierungszeit und führt zu einer aufgeblähten Ausgabe.

• Es gab keine Möglichkeit, private Mitglieder oder Platzhalter-Selektoren zu definieren, auf die nachgeschaltete Stylesheets nicht zugreifen konnten.

Das neue Modulsystem und die @useRegel adressieren all diese Probleme.

Darüber hinaus @importwird es in den nächsten Jahren schrittweise auslaufen und schließlich vollständig aus der Sprache entfernt.

Um über die Best Practices in Sass auf dem Laufenden zu bleiben, sollten Sie vorerst Dart-Sass (dh Sass ) verwenden.