コメント募集: 新しい埋め込み プロトコル

あなたがEmbedded Sass Protocolのホストパッケージの作成者でないなら、このブログ記事はスキップして構いません。もっとも、あなたが十分にオタクなら、興味深いと思うかもしれません が！

私たちはEmbedded Sass Protocolにいくつかの破壊的な変更を加えることを計画しており、新しいやり方を決定する前にあなたのフィードバックを求めています。私たちは、全体的な中断の数を最小限に抑えるために、一度に多くの破壊的な変更を行うつもり です。

私たちは2つの主要な破壊的な 変更を計画しています。

1. Dart Sassの埋め込みホストは、独立した実行可能ファイルとしてリリースされなくなります。今後は、メインのDart Sass実行可能ファイルにバンドルされ、sass --embeddedを実行することでアクセスできるようになります。

2. 埋め込みプロトコル内のすべてのパケットは、プロトコルバッファの定義で宣言するのではなく、パケット構造の一部としてコンパイルIDを含むようになりました 。

この機会を利用して、さらに3つの小規模な破壊的な 変更も導入します。

1. 埋め込みプロトコルの仕様とプロトコルバッファの定義は、言語とJS APIへの変更と同時に更新できるように、Sass言語リポジトリに移動しました。

2. 埋め込みプロトコルは、プロトコルバッファの言語機能を使用して、オプションフィールドを明示的に宣言するようになりました。これは、さまざまなフィールドの「デフォルト値」が設定されていないとはみなされなくなったことを意味し ます。

3. CompilationSuccess.loaded_urlsフィールドは、コンパイルが失敗した場合でも利用できるように、CompilationResult.loaded_urlsに移動されました。これにより、ウォッチャーの実装は、失敗したコンパイルをやり直すためにどのファイルを監視する必要があるかを知ることができ ます。

リポジトリの組織変更はすでに完了していますが、プロトコル自体の変更は、言語 リポジトリの提案で完全に文書化されています。

実行可能ファイルの結合実行可能ファイルの結合パーマリンク

Embedded Dart SassをメインのDart Sass実行可能ファイルに統合する主な利点は、埋め込みホストが標準のDart SassコマンドラインAPIをユーザーに簡単に公開できるようにすることです。これで、埋め込みホストをインストールしたすべてのユーザーが、ネイティブのDart VM 速度で完全なDart Sass実行可能ファイルを利用できるようになります。

これは、個別のリポジトリと管理する必要のあるリリースプロセスの数を減らすことで、Sassチームの組織を簡素化するのにも役立ち ます。

ワイヤーレベルのコンパイルIDワイヤーレベルのコンパイルID パーマリンク

埋め込みコンパイラの側で、特に並行性を向上させるために、コンパイルIDをプロトコルレベルに引き出しています。埋め込みコンパイラによって行われるSassコンパイルは、互いに状態を共有しないため、理論的には完全に別々のワーカースレッドで実行できます。ただし、現在の埋め込みプロトコルでは、各メッセージを正しいワーカースレッドに転送するには、メインスレッドでメッセージ全体を解析してどのコンパイルに属しているかを判断し、ワーカースレッドで再度解析して実際に処理する必要があり ます。

コンパイルIDをプロトコル自体の一部にすることで、この問題が解決されます。各エンドポイントは、IDを読み取り、コンパイルを処理しているワーカースレッドを検索し、メッセージの残りを解析せずに、そのスレッドにメッセージを渡すことができます。これにより、並行性がより簡単かつ効率的になり、大規模なコンパイルができるだけ早く完了するようになります 。