Facebook が CSS code_html/css_WEB-ITnose の品質をどのように保証しているかを見てみましょう。

Facebook では、信頼性の高い高品質のサービスを世界中のユーザーに提供するために、数千人のエンジニアがさまざまな製品ラインに取り組んでいますが、コードの品質管理においても特有の課題に直面しています。膨大なコードベースに直面しているだけでなく、機能の多様性が増加しているため、特定のモジュールをリファクタリングして改善したい場合、他の多くのモジュールに影響を与えることがよくあります。特に CSS では、常に変化する何千もの CSS ファイルを処理する必要があります。以前は、コード レビュー、コード スタイル仕様、リファクタリングを通じてコードの品質を確保するために協力することに重点を置いていましたが、依然として多くのエラーが目に留まり、コード ベースに送信されていました。基本的なコードのエラーを検出し、一貫したコーディング スタイルを確保するために、独自に構築した CSS Linter を使用してきましたが、まだ多くの問題があるため、この記事でその方法についても説明したいと思います。 CSS のコード品質を保証します。

正規表現では十分ではありません: 以前は正規一致を使用していましたが、これは良くありませんでした。

古い Linter は主に多くの正規表現に基づいて CSS の文法を抽出しました。おそらく次のようになります。 🎜>

preg_match_all( // This pattern matches [attr] selectors with no preceding selector.      '/\/\*.*?\*\/|\{[^}]*\}|\s(\[[^\]]+\])/s', $data,    $matches,    PREG_SET_ORDER | PREG_OFFSET_CAPTURE); foreach ($matches as $match) {   if (isset($match[1])) {     raiseError(...);   }

基本的に、検出ルールには特別な一致ルールを追加する必要がありますが、これは保守が非常に難しく、パフォーマンスに大きな問題があります。ルールごとにファイル全体を走査する必要があるため、パフォーマンスが非常に低下します。

抽象構文ツリー

正規表現にはもう飽きたので、より優れた、より詳細な CSS インタープリターを作成したいと考えています。 CSS自体も言語であり、プレーンテキストファイルとして扱うのは良くないので、抽象構文木であるASTを使ってパーサーを構築する予定です。この新しい処理方法により、パフォーマンスが大幅に向上しました。たとえば、コード ベースには次の CSS コードがあります。

{  display: none:  background-color: #8B1D3;  padding: 10px,10px,0,0;  opacity: 1.0f;}

このコード スニペットの存在は、視力の良い人だけが見ることができます。特定の属性名が間違っている、16 進数のカラーコードが間違っている、セパレータが間違っているなどの問題。ブラウザーはエラーを積極的に報告しないため、開発者自身がエラーを見つけることが困難になります。具体的な実装に関しては、PostCSS が優れたツールであることがわかったので、新しいリンター ツールとして Stylelint を選択しました。これは PostCSS に基づいて構築されており、非常に柔軟で、優れたコミュニティがあります。

JavaScript の Esprima や ESLint と同様に、Stylelint は完全な AST へのアクセスを提供し、現在の検出ルールなどのさまざまな状況に応じて特定のコード ノードにより迅速かつ簡単にアクセスできるようにします。次のように記述されます。

root.walkDecls(node => {  if (node.prop === 'text-transform' && node.value === 'uppercase') {    report({      ...    });  }});

次のように、線形勾配などのいくつかの基本関数を渡すこともできます:

// disallow things like linear-gradient(top, blue, green) w. incorrect first valueroot.walkDecls(node => {  const parsedValue = styleParser(node.value);  parsedValue.walk(valueNode => {    if (valueNode.type === 'function' && valueNode.value === 'linear-gradient') {      const firstValueInGradient = styleParser.stringify(valueNode.nodes[0]);      if (disallowedFirstValuesInGradient.indexOf(firstValueInGradient) > -1) {        report({          ...        });      }    }  });});

検出ルールは次のように記述されます。より読みやすく、理解しやすいです。どのような CSS フォーマットが使用されていても、ルールや宣言がどこに配置されていても、正常に動作します。

カスタム ルール: カスタム ルール

デフォルトでは、declaration-no- important、selector-no-universal、selector-class-pattern などの Stylelint の組み込みルールの一部を使用します。カスタム ルールを追加する方法は、組み込みのプラグイン メカニズムを参照できます。たとえば、

• slow-css-properties を使用して、不透明度などのパフォーマンスが低い一部のプロパティを警告します。または、box-shadow

• filters-with-svg-files で SVG フィルタリングが Edge でサポートされていないことを警告します

• use-variables で警告します一部の変数は組み込み定数に置き換えられます

• common-properties-whitelist は、存在しないプロパティが誤って書き込まれているかどうかを検出します

• mobile -flexbox は、古いモバイルブラウザでサポートされていない属性を検出します。

• text-transform-uppercase は、適切に動作しない「text-transform: uppercase」を警告します。一部の言語で フレンドリー

また、いくつかのルールと広告プラグインを Stylelint に提供しました。

自動置換: 自動置換

Linter が特定の問題を検出すると、ルールに従って置換する必要があるかどうかを尋ねられます。この機能により、手動での修正や修正にかかる時間を大幅に節約できます。一般に、コードを送信する前に、リンターによって報告されたエラーを確認し、これらのエラーを修正します。残念ながら、Stylelint には自動フォーマットおよび修復メカニズムが組み込まれていないため、Stylelint ルールの一部を書き換えて自動置換および修復機能を追加しました。

Test all the things

我们老的Linter还有个问题就是没有单元测试，这点就好像代码上线前不进行单元测试一样不靠谱。我们面对的可能是任意格式的处理文本，因此我们也要保证我们的检测规则能够适用于真实有效的环境，这里我们是选择了Jest这个测试框架，Stylelint对它的支持挺好的，然后大概一个单元测试是这个样子：

test.ok('div { background-image: linear-gradient( 0deg, blue, green 40%, red ); }',   'linear gradient with valid syntax');test.notOk('a { background: linear-gradient(top, blue, green); }',   message,     'linear-gradient with invalid syntax');

What‘s next

换一个靠谱的CSS Linter工具只是保证高质量的CSS的代码的第一步，我们还打算添加很多自定义的检测规则来捕获一些常见的错误，保证使用规定的最佳实践以及统一代码约定规范。我们已经在JavaScript的校验中进行了这一工作。

另外对于React社区中存在的CSS-in-JS这种写法，对于CSS Linter也是个不小的挑战，现在的大部分的Linter都是着眼于处理传统的CSS文件，以后会添加对于JSX的处理规范吧。