少ないものからSassに切り替えた経験

バニラCSSからCSSプリプロセッサへの切り替えについては多くのことが書かれていますが、それには正当な理由があります。プリプロセッサは、ブラウザだけでは得られないパワーと制御を追加します。その記事からプリプロセッサの長所を称賛する Etsyの詳細な「大規模なSCSSへの移行」私はそれらすべてをむさぼり食ったような気がします。

でハッシュタグ、私たちはほとんど書かれていないことをしました—あるプリプロセッサから別のプリプロセッサに切り替えることです。早い段階で、スプラウトは採用しましたもっと少なく ;昨年末、CSSのような構文であるSCSSに切り替えることを決定しました。サス。移行がスムーズに行われるように時間をかけました。この経験から、LessとSassの深い違いが浮き彫りになりました。

どうして？

私たちが学んだことに到達する前に、あなたの最初の質問、つまり正当な質問は、「なぜわざわざするのか」ということです。変数とミックスイン、@ imports、カラー関数の恩恵はすでに受けています。確かに、Sassにはいくつかの機能があります。マップそして機能、しかし、私たちはそれらなしでこれまでにそれを達成しました。

切り替える主な理由は2つあります。

コミュニティ： githubでlibextension：scssを検索してから、lib extension：lessを検索します。これを書いている時点で、結果は明らかです：120,234 SCSSファイル、29,449少ないファイル。切り替えにより、さまざまな優れたアイデアや、泳ぐためのより大きなオープンソースプールにアクセスできます。人気のあるBootstrapライブラリでさえ、Lessが実行可能であり続けている理由の1つであると発表しました SCSSに切り替えています。
速度： Libsass 岩。私たちのスタイルのビルド時間は500％以上改善されました。 LibsassはまだSass仕様の最新バージョンに追いついていないが、何も欠けているとは感じていない。

どうやって？

コンパイルされたCSSには、約19,000のセレクターがあります。切り替え後、コンパイルされたCSSはほぼ同一である必要がありました。この移行がお客様に見えないようにする必要がありました。そして、現在進行中の機能はどうですか？私たちの最近の作曲アップデート 3,837行のスタイルを変更しました—そのチームはどのようにして安全にミッドストリームを切り替えることができますか？

3つのオプションを検討しました。

最初にすべてをCSSにコンパイルします。 これは、ユーザーが同じスタイルを取得していることを100％の精度で確認し、実際に1日でスイッチを切る唯一の方法です。きれいな休憩のアイデアは常に魅力的ですが、新しいコードは必ずしも良いコードではありません。のようなツールでも sass-convert そして css2compass 、再構築に費やす時間は、他のオプションを大幅に上回ります。
SCSSでのみ新しいスタイルを記述します。 砂に線を引くことを検討しました— 古くて破壊されたものは少ない。サスは新しい暑さです。最終的に、私たちはこの概念を拒否しました。すぐに切り替えることで多くのことが得られ、2セットのミックスインと変数の間でパリティを維持することは誰も望んでいませんでした。
すべてのLessファイルをSCSSに変換し、壊れているものを修正します。 履歴を破棄するか、維持する別のビルドタスクを追加することに直面して、すべてを変換することに着手しました。

家の掃除

SCSSはLessとそれほど違いはありませんね。「「 LessからSassへの変換」は、.awesome-mixin（）と@mixin awesome-mixin（）など、最も明白な構文の違いを変更するための一連の正規表現検索を共有しています。それらの正規表現検索はにロールアップされます less2sass 、すべてのファイルを実行しました。

でも、そんなに簡単だったら、ブログを書くことはあまりないでしょう。 less2sassスクリプトへのいくつかの長引くプルリクエストは、次のようなその見落としのいくつかを強調しています。文字列補間の違い。さらに困難なのは、変換後に発生したビルドエラーで、単純な正規表現では解決できない大きな違いが浮き彫りになりました。率直に言って、いくつかの悪いCSSも見つかりました。

これらのビルドエラーを取得し、修正する必要があるもののリストを作成しました。スタイルを変換する前に、ほとんどのビルドエラーを修正できることがわかりました。変換する前に、Lessファイルをクリーンアップすることにしました。

Fixin’Mixins

LessとSassが条件を処理する方法の違いから始めました。これが私たちが持っていた単純なグラデーションミックスインです：

Sassは単純な@ if…@ else構造を提供しますが、私たちのミックスインは、Lessが呼ぶものを採用しましたミックスインガード。グラデーションミックスインの場合、ベンダープレフィックスのドラフト構文からW3C構文に変更するために使用していました。このミックスインを書き直す必要があることはわかっていました。

次に、停止して、すべてのミックスインを詳しく調べました。それらのほとんどはベンダープレフィックスを追加し、上記のグラデーションミックスインなどのブラウザの違いを解決しました。入る自動プレフィックス、CSSを解析し、サポートされているブラウザのリストに基づいてベンダープレフィックスを適用するツール。 Autoprefixerをビルドに追加することで、9つのミックスインを排除しました。ボーナスとして、Autoprefixerは不要なベンダープレフィックスを削除します。これにより、CSSのほこりっぽいコーナーを特定し、コンパイルされたファイルを小さくすることができます。

ここでの経験から得られる良い教訓：削除できるものの変換やリファクタリングに時間を無駄にしないでください。

注目に値するもう1つのミックスインの違い：パラメータをセミコロンで区切ることはあまりお勧めしません。このように書かれたのはごくわずかでしたが、ミックスインの定義と適用場所をすべて変更する必要がありました。幸い、Lessはセミコロンとコンマの両方をサポートしているため、変換手順の前にこの変更を行うことができます。

13エンジェルナンバー

アンパサンドの乱用

ミックスインに対処した後、ビルドエラーの別の原因に注意を向けました。アンパサンド。これは、SassとLessの両方で最も強力な演算子の1つであり、非常によく似ています。そうでない場合を除いて。そして、それらは非常に異なった働きをします。

たとえば、19,000のセレクターを使用すると、特異性の問題が発生し、多くの場合、次のようにすばやく解決されることが想像できます。

疑うように、Lessはh1.modal-headerを生成しますが、Sassはチョークします。私たちはそれを修正しようとしました：

Ruby Sassでうまく機能しますが、この記事の執筆時点では、 Libsassはまだこの使用をサポートしていません。この場合、RubySassへの切り替えも検討していませんでした。代わりに、.modalの範囲外でh1.modal-headerを書き出しました。これは問題の兆候であることがわかっているため、セレクターをスコープから引き出し、コメントを付けて呼び出すことで、コード内でこれらの問題をより簡単に特定できます。

アンパサンドをこのようにミックスインで使用すると、さらに悪化しました。ボタン用のLessミックスインの抜粋を次に示します。

繰り返しになりますが、@ at-rootディレクティブはLibsassでは役に立ちませんでした。この場合、特異性のオーバーライドの根本原因を調べて解決する必要がありました。（幸いなことに、他の場所で3つの過度に特定されたスタイルを削除することで修正しました。）

LessアンパサンドとSassアンパサンドのもう1つの違いは、実際に役立ちました。

私たちの期待は、.checkbox-wrap> .checkbox-widget、.radio-wrap> .radio-widgetでした。ただし、Lessはより多くの再帰でアンパサンドを処理し、次のようにコンパイルします。

ラジオボタンにチェックボックスウィジェットを使用したことはありませんでした。幸い、Sassは、コンパイルされたCSSを調べていなかったため、私たちが知らなかった問題を実際に解決しました。

教訓：コンパイルされたCSSを頻繁に確認します。そうしないと、ユーザーが何をダウンロードしているかがわかりません。

結果の比較

ミックスインを修正および削除し、アンパサンドの不一致を解決し、正常に変換されなかったその他のビットに対処するための更新は、1か月の間に7回のコミットで発生しました。家を掃除し、将来のリファクタリングの機会を特定するのは良い気分でした。

ただし、ソースコードがどのように見えるかは問題ではありません。重要なのは、ユーザーに配信されるものです。生成することを検討しました AST コンパイルされたCSSを比較します。いくつかの調査と実験の結果、必要なのは、コンパイルされたCSSでほとんど変更がなかったかどうかを知る方法だけであることが明らかになりました。したがって、古き良きdiffで十分です。diffが小さいほど良いです。各プルリクエストには、Lessコンパイルの前後の結果の差分が付属しています。 Xcode開発者ツール FileMerge 結果を並べて比較するのに非常に便利でした。予期しないものが見つかった場合は、調査に戻りました。

正規表現の検索と置換のスタンピードを実行し、実際にファイルをSCSSに変換した後、FileMergeとdiffを使用しました。ただし、2つの異なるプリプロセッサによってコンパイルされた結果により、タブとブラケットの配置が異なるため、差分が役に立たなくなりました。前後のCSSの形式を正規化するための追加の手順を追加しました単純なノードスクリプト。それはCSSを最小化し、それを美化します。これ以上簡単なことはありません。

フォーマットを正規化することは大いに役立ちましたが、差分をくまなく調べるには、まだ約2日間のレビューが必要でした。やりがいのあるプロセスですが、骨の折れる作業です。カスタムASTソリューションがレビューのスピードアップに役立つとは思えません。すべての違いに対処する必要がありました。

しかし、違いはわずかでした。わずかに異なる順序のセレクター、小数の丸め、さらには色関数の結果のわずかな違い。 Sassed-up CSSを本番環境にプッシュする前に、それぞれの違いを注意深くチェックしました。

次は何ですか

一度マージされると、進行中の作業はほとんど停止しません。事前に行われたすべての準備作業のおかげで、まだ開発中のファイルが少なくなり、変換が簡単になりました。全員が約2日で稼働しました。再設計されたComposeチームでさえ、数時間のうちにSCSSへの道を正規表現することができました。スイッチを引く前に事前に計画を立て、既存のスタイルをクリーンアップすることで、すべての違いが生まれました。

現在、パターンの識別、大きなCSSファイルのモジュールへの分割、未使用のセレクターの本番環境でのCSSの監査、およびASTやその他のCSSの解析済み表現を比較するためのツールにより多くの時間を費やしています。 19,000近くのCSSセレクターがあることを述べましたか？私たちはそれに取り組んでいますが、それはまったく別の記事です。

友達と共有してください: