Stylelintは、CSS、SCSS、Less、PostCSSなどのスタイルシートを対象とした静的解析ツールで、構文エラーや慣習違反、ベンダー固有プロパティの混入を検出する。2015年にDavid Clark氏とRichard Hallows氏らによって開発が始まり、当時主流だったCSSLintやSCSS-Lintを置き換える存在として急速に普及した。PostCSSのプラグインアーキテクチャを活用し、AST（抽象構文木）レベルで解析することで、文字列マッチに頼る素朴なリンターよりはるかに高精度な検査を実現している。現在ではWordPress、GitHub、Booking.comなどのフロントエンドチームが採用し、デザインシステム運用の土台として浸透している。
この記事の目次
- PostCSS基盤と170超のルール
- 設定とshareable config
- プラグインで広がる適用範囲
- エディタとCIへの組み込み
- まとめ
PostCSS基盤と170超のルール
Stylelintの解析基盤はPostCSSで、入力されたCSSをそのまま文字列処理するのではなく、いったんASTへ変換してから検査ルールを適用する設計になっている。そのため、メディアクエリのネスト、@supportsクエリ、CSSカスタムプロパティの参照、SCSSの@if/@eachといった複雑な構造に対しても、文脈を踏まえた精度の高い指摘ができる。PostCSS自体はAndrey Sitnik氏の作で、Autoprefixerなどの変換系プラグインを生み出した実績ある基盤として知られ、その上に乗ることでStylelintは安定したパース能力を確保している。
本体に同梱されるルールは170を超え、color-no-invalid-hexのような誤記検出から、selector-class-patternによるBEM命名規約の強制、declaration-block-no-duplicate-propertiesのような重複検出まで多岐にわたる。ルールはon/offの二値ではなく、レベル（warning/error）と細かなオプションを受け取る形で柔軟に設定できる。プロジェクトに合わせて自社のCSS命名規約を強制したり、IE時代の不要なベンダープレフィックスを排除したりといった、現実的な利用シーンに合わせた調整が可能だ。
設定とshareable config
Stylelintは.stylelintrc.json、.stylelintrc.js、package.jsonのstylelintキーなど、複数の設定ファイル形式に対応する。ESLintと同じくshareable configの仕組みがあり、stylelint-config-standardやstylelint-config-recommendedといった既製の設定を読み込むだけで、業界標準的なルールセットが手に入る。ここから自社の好みを追記して上書きする、というスタイルが定番で、ゼロから170超のルールを評価する必要はない。
SCSSやLess、CSS-in-JSなど、純粋なCSS以外を扱う場合は、postcss-scss、postcss-less、postcss-styled-syntaxなどのカスタムパーサを指定する。Stylelint自体は構文を抽象化したASTで処理するため、こうした派生記法でも同じルールが効くのが強みだ。また整形系の責務はprettierへ譲り、stylelint-config-prettierで競合ルールを無効化して併用するのが現代的なベストプラクティスとして定着している。「論理的な書き方の問題はStylelintが、見た目の整形はPrettierが担当する」という分業がフロントエンド界の標準になりつつある。
プラグインで広がる適用範囲
プラグイン機構が充実しており、本体ルールだけでは足りない領域はサードパーティのstylelint-プラグインで補完できる。stylelint-orderは「位置プロパティの後にレイアウトプロパティを書く」など宣言順序を強制し、巨大なCSSファイルでも整然とした構造を維持する助けとなる。stylelint-scssはSCSS固有の構文、たとえば@useと@importの使い分けや@functionの命名規則などを扱い、stylelint-declaration-strict-valueは「colorプロパティには16進値ではなく変数を使う」といったデザインシステムの強制に役立つ。
アクセシビリティ観点ではstylelint-a11yがあり、outline: 0をうっかり書いて :focus を見えなくする、line-heightが小さすぎる、といった指摘を担う。プラグインはnpmからインストールし、stylelintrcのpluginsキーに登録するだけで使えるため、プロジェクト固有の要件を後付けで足しやすい。結果として、デザイントークンの体系を導入するチームや、社内コンポーネントライブラリの設計品質を維持したいチームは、Stylelint＋カスタムプラグインで自社流儀を機械的に強制する運用を構築している。
エディタとCIへの組み込み
現代のフロントエンド開発では、Stylelintは単独で使うのではなく、ESLintやPrettierと組み合わせて統合運用するのが標準だ。VS Codeのstylelint公式拡張をインストールし、保存時に自動修正を有効化しておけば、ほとんどの問題は手元で解決する。git commit時にはHuskyとlint-stagedを使い、ステージされたCSS/SCSSファイルだけにstylelint --fixをかけることで、巨大プロジェクトでもオーバーヘッドを抑えながら品質を保てる。
CIではnpm run lint:cssといったnpm scriptで実行し、警告が一定数を超えるとビルドを失敗させる構成が一般的だ。Stylelintはreporterをカスタマイズでき、CI環境ではGitHub Actions向けのstylelint-formatter-githubのようなフォーマッタを使うことで、エラー行に直接アノテーションを付けることもできる。近年はNext.jsやNuxt、Astroといったフレームワークがプロジェクト生成時にStylelint設定を含めるケースも増え、フロントエンド開発者にとっては「あって当たり前」の存在になりつつある。
まとめ
Stylelintは、PostCSS基盤の上で170超のルールと豊富なプラグインを通じて、CSS/SCSSの品質を機械的に守るリンターである。shareable configとPrettierとの分業、プラグインによる自社規約の強制、エディタとCIへのシームレスな組み込みなど、現代フロントエンドの定番ツールとして確固たる地位を築いている。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント