Request for Comments: Neues eingebettetes Protokoll

Wenn Sie kein Autor eines Host-Pakets für das Embedded Sass Protocol sind, können Sie diesen Blogbeitrag überspringen – obwohl er für Sie als großen Nerd vielleicht trotzdem interessant ist unabhängig davon!

Wir planen, eine Reihe von nicht abwärtskompatiblen Änderungen am Embedded Sass Protocol vorzunehmen, und wir möchten Ihr Feedback einholen, bevor wir den neuen Weg festlegen. Wir beabsichtigen, eine Reihe von nicht abwärtskompatiblen Änderungen auf einmal vorzunehmen, um die Gesamtzahl der Störungen auf ein Minimum zu beschränken.

Wir planen zwei größere nicht abwärtskompatible Änderungen

1. Der eingebettete Dart Sass-Host wird nicht mehr als separate ausführbare Datei veröffentlicht. Er wird jetzt in die Haupt-Dart-Sass-ausführbare Datei integriert und ist durch Ausführung von sass --embedded zugänglich.

2. Jedes Paket im eingebetteten Protokoll enthält nun eine Kompilierungs-ID als Teil der Paketstruktur, anstatt sie in den Protocol Buffer-Definitionen zu deklarieren.

Wir nutzen diese Gelegenheit, um auch drei wesentlich kleinere nicht abwärtskompatible Änderungen einzuführen

1. Die Spezifikation für das eingebettete Protokoll und die Protocol Buffer-Definition wurden in das Sass-Sprach-Repository verschoben, damit sie gleichzeitig mit Änderungen an der Sprache und der JS API aktualisiert werden können.

2. Das eingebettete Protokoll deklariert nun optional Felder explizit unter Verwendung der Sprachfunktion von Protocol Buffers. Das bedeutet, dass "Standardwerte" für verschiedene Felder nicht mehr als "nicht gesetzt" betrachtet werden.

3. Das Feld CompilationSuccess.loaded_urls wurde zu CompilationResult.loaded_urls verschoben, sodass es auch dann verfügbar ist, wenn eine Kompilierung fehlschlägt. Dies ermöglicht es Watcher-Implementierungen, zu wissen, welche Dateien beobachtet werden müssen, um eine fehlgeschlagene Kompilierung erneut durchzuführen.

Die Änderungen an der Repository-Organisation wurden bereits vorgenommen, aber die Änderungen am Protokoll selbst sind in einem Vorschlag im Sprach-Repository vollständig dokumentiert.

Kombination von ausführbaren DateienKombination von ausführbaren Dateien Permalink

Der Hauptvorteil der Integration von Embedded Dart Sass in die Haupt-Dart-Sass-ausführbare Datei ist es, eingebetteten Hosts eine einfache Möglichkeit zu bieten, die standardmäßige Dart Sass-Befehlszeilen-API Benutzern zur Verfügung zu stellen. Jetzt hat jeder Benutzer, der einen beliebigen eingebetteten Host installiert, die vollständige Dart Sass-ausführbare Datei zu nativen Dart VM-Geschwindigkeiten zur Verfügung.

Dies hilft auch, die Organisation des Sass-Teams zu vereinfachen, indem die Anzahl der separaten Repositories und Veröffentlichungsprozesse, die wir verwalten müssen, reduziert wird.

Wire-Level-Kompilierungs-IDWire-Level-Kompilierungs-ID Permalink

Wir ziehen die Kompilierungs-ID auf Protokollebene, um eine bessere Nebenläufigkeit zu ermöglichen, insbesondere auf Seiten des eingebetteten Compilers. Sass-Kompilierungen, die vom eingebetteten Compiler durchgeführt werden, teilen keine Zustände untereinander, was bedeutet, dass sie theoretisch in völlig separaten Worker-Threads ausgeführt werden könnten. Mit dem derzeitigen eingebetteten Protokoll erfordert die Weiterleitung jeder Nachricht an den richtigen Worker-Thread das Parsen der gesamten Nachricht im Haupt-Thread, um festzustellen, zu welcher Kompilierung sie gehört, und dann das erneute Parsen im Worker-Thread, um sie tatsächlich zu bearbeiten.

Die Kompilierungs-ID als Teil des Protokolls selbst zu machen, löst dieses Problem. Jeder Endpunkt kann die ID lesen, den Worker-Thread abrufen, der die Kompilierung bearbeitet, und die Nachricht an diesen Thread weiterleiten, ohne den Rest der Nachricht zu parsen. Dies macht die Nebenläufigkeit sowohl einfacher als auch effizienter, was dazu beiträgt, dass große Kompilierungen so schnell wie möglich erfolgen.