フロントエンド開発はすでに円熟期に入っており、コード品質管理ツールの使用も増えてきました。このことがよく表れているのは、JavaScriptのエコシステムです。JavaScriptにおけるLintツールは、フロントエンド開発者がコードの正しい構成と一貫性を保証するために使われます。ツールに関する最近の調査では、開発者の大多数がJavaScriptでLintツールを使っていると答えました。
CSSコーディングでは、コード品質管理ツールの使用に向けた動きはいくぶん緩やかで、同様の調査では開発者の大半がワークフローでCSSのLintツールを使っていないと答えました。
この記事では、スタイルシートにおけるlintのレベルを向上させてきたツールの1つ「stylelint」を解説します。
取り上げるCSSコードはSassをはじめ、プリプロセッサー言語に置きかえられます。Stylelintは素のCSSだけでなくSassファイルやLessファイルの評価にも使用できます（記事の後半で説明します）。
CSSにおけるLintのちょっとした歴史
CSSのLintがコンセプトとして最初に導入されたころの評価はかなり分かれていました。2011年に「CSS Lint 」が世に出て間もなく、Matt Wilcoxの記事「CSS Lint is harmful（CSS Lintは迷惑）」を読んだことを思い出します。「CSS Lint」のルールに融通がきかない側面があると批評し、コミュニティの多くの人が共感しました。
振り返ってみると、「CSS Lint」同様、JavaScriptで当初利用できたLintツール「JSLint」も融通がきかず、柔軟性があるとは言ませんでした。「JSHint」や「ESLint」などのツールが登場してJavaScriptのLintはレベルアップしましたが、CSSに同様の代替ツールはありませんでした。
この状況は「stylelint」の登場まで続きました。
Stylelintとは
「stylelintは現在利用できるCSS用Lintのベストツール」といえる理由はいくつかあります。
まず、stylelintは柔軟で、必要に応じてルールを設定し、自在に組み合わせることができます。stylelintは多くのルールが利用でき、その数は150を超えます（プリプロセッサー構文用の言語固有のルールを除く）。少し時間を取ってこれらのルールを見ていくと、記述するスタイルにぴったりのルールセットを実装するときに役立つでしょう。
stylelintは柔軟で、CSSだけでなくSCSSやLessといったCSSライクな構文にも対応します。プリプロセッサーコードも素のCSSもLintできるのです。
さらに、stylelintには優れたドキュメントがあります。どんなルールが使えるのか知りたいなら、利用可能なルールをすべて取り上げたドキュメントを、新しいルールを使うなら開発者ガイドを参照ください。
Stylelintでできること
どんな言語でも、開発時にLint工程を追加すると、作成中のコードが一貫性を持ち、エラーを減らせます。CSSにもあてはまり、stylelintを使えば多くの課題に対処できます。
構文エラー
構文エラーは人に依存しないので、ハイライトすればわかります。
次の例で考えます。
.element {
color: #EA12AE1;
disply: block;
}上のコードには2種類の構文エラーがあります。無効な16進数カラーコードの記述と、displayプロパティの宣言でのスペルミスです。
基本的な構文エラーで、stylelintのcolor-no-invalid-hexルールとproperty-no-unknownルールで見つけられます。手動でミスを発見する頭痛の種から開放されます。
フォーマットと一貫性
CSSのコードスタイルの好みは主観的になる場合があります。私好みのCSS記述方法はみなさんの好みとは違うでしょう。だからこそ、CSSのLintツールが一連のルールを押しつけるのではなく、ユーザーの好みに合わせられることが重要です。
次のスタイルで考えます。
.listing {
display: block;
}
.listing-item
{
color:blue;
}
.listing-img{
width : 100%}
.listing-text { font-size: block; }
.listing-icon {
background-size: 0,
0; }上のルールセットは正しいCSSで書かれていますが、明らかに一貫性がありません。それぞれの宣言でスペースの入れ方が異なり、ブロックごとにフォーマットが微妙に違います。
これは、考えられるCSSフォーマットのほんの数例です。実際には微妙に異なるフォーマットが数百もあります。スタイルシート全体（または複数のファイル）にわたって不一致があると、コードの可読性や保守性が損なわれます。
複数の開発者が作業しているプロジェクトは、微妙に違うスタイルで記述するため、不一致が生じます。一連のフォーマットルールについて話し合い、合意して全員が守るといいでしょう。
Stylelintでは、開発者や開発チームの好みのスタイルフォーマットに合わせてルールセットをカスタマイズできます。好みが違っても、ルールがプロジェクト全体に一貫して適用されているかチェックできます。
スタイルの重複を減らす
セレクタ、プロパティ共に、スタイルシート内で重複するとデバッグ時に悩みの種になります。
以下のCSSを見てください。
/* Property duplication */
a {
display: block;
color: orange;
font-size: 1.2rem;
display: inline; /* duplicate */
}
/* Selector duplication (1)
Same selector, at different points in stylesheet */
.foo {}
.bar {}
.foo {}
/* Selector duplication (2)
The same group of selectors, simply ordered differently */
.foo, .bar {}
.bar, .foo {}Stylelintには、コード内の上記のような重複をチェックするルールがあります。たとえばプロパティの重複をキャッチするdeclaration-block-no-duplicate-propertiesルールです。
同一のプロパティがフォールバック値用に定義されているといった、意図的な重複を無視する設定もできます。
.example {
font-size: 14px;
font-size: 1.2rem; /* will override the above if browser supports rem */
}チェックのベストプラクティス
CSSにおけるベストプラクティスは主観的ですが、stylelintは「エラー」をどうチェックしても柔軟に対応します。
この分野のベストプラクティスの1つは、プリプロセッサーコードの記述で特定のセレクタのネストが深くなりすぎた場合にエラーを返します。スタイル指定のレベルを合理的な範囲に保ち、手に負えなくなるのを防ぎます。
「開発者が違えばユースケースも違う」は、「正当」がプロジェクトによって異なることを意味します。たとえば古典的なスタイルシートを使っているなら、ネストの深さにまずいところがないか確認したいと思うかもしれません。max-nesting-depthルールを使えば、許可するネストの深さを独自に定義してチェックできます。このルールは、プリプロセッサーを使うどのようなプロジェクトにも役立てられるのです。
言語機能の制限
stylelintで利用できる究極のチェックセットは、ルールガイドで「Limit language features（言語機能の制限）」と呼ばれるチェックセットです。スタイルシートを扱う際に独自の機能ルールを徹底できます。
よくある例は、Autoprefixerをはじめとしたツールを使ってスタイルにベンダープレフィックスを自動追加するケースでしょう。このシナリオで、開発者がベンダープレフィックスを手動で追加している場合、警告やエラーを返し、プレフィックスなしのスタイルに対するものとしてツールが実行されて、不要なプレフィックスがコードに追加されません。Stylelintの「value-no-vendor-prefix」ルールが実行します。
ルールの例は名前付きカラー指定の禁止や小数点以下の桁数の指定、必要な場合許可しない特定のプロパティのリストを指定できるなど多岐にわたります。
これらのルールは本質的に非柔軟的ですが、自由に選んで利用できます。プロジェクトのLintルールは、開発者や開発チームが望む記述スタイルに合わせてオーダーメイドできるのです。
Stylelintを使う
stylelintでできることを紹介してきました。次はstylelintがどれほど簡単に設定できるか解説します。
搭載されているルールセットと同様、stylelintは柔軟性に優れています。利用できるプラグインが多く、AtomやSublime Text、Visual Studioコード用のエディタープラグインと同様、好みのビルドツールに簡単に統合できます。
独自のルールセットを設定する方法はいくつかあります。もっとも簡単な方法は、.stylelintrcファイルをプロジェクトのルートディレクトリに作成します。そのファイルで独自のルールを構築します。
{
"rules": {
'block-closing-brace-newline-before': 'always-multi-line',
'block-closing-brace-space-before': 'always-single-line',
'color-no-invalid-hex': true,
'comment-no-empty': true,
'unit-case': 'lower',
'unit-no-unknown': true,
// etc...
}
}次いで、たとえばGulpやwebpackのビルドの一部でstylelintタスクを実行すると、上の設定が登録され、そのルールでスタイルにLintを適用します。
ESLintなどJavaScriptのLintツール同様、既存の設定をベースとした独自のルールを追加できます。Stylelintには拡張可能な推奨ベース構成があります。SUIT CSSの手法に基づくより厳格なルールセットから拡張するという選択肢もあります。
時間を割いて利用可能なルールを概観し、開発者と開発チームが満足する設定を作成します。使い勝手が良ければ、一歩進んで設定をインストール可能なnpmモジュールにできます。上の拡張可能なルールセットも同様です。stylelintの設定をインストールして、設定をプロジェクト全体に同期できます。
プリプロセッサーコードにLintを適用
stylelintはCSS同様、簡単にSassやLessにLintを適用できます。
stylelintを用途に合わせて設定します。Gulpやwebpackといったビルドツール用のプラグインを使っているなら、stylelintのsyntaxオプション用の値を渡せます。syntaxオプションにはLintを適用する構文に対応する値としてlessやscssなどがあります。
たとえば.scssファイルへのLintの適用を指定するには、stylelintのオプションとしてオブジェクトを渡します。
{
syntax: 'scss'
}プリプロセッサーコードにstylelintを使ったLintの適用方法は、stylelintドキュメント中の優れたセクションを参照ください。
Lintを始めよう
stylelintはCSSにおけるLintを比較的短期間にレベルアップしてきました。stylelintには柔軟性があり、そのルールは広範に及びます。思いのままに詳しく設定したり省いたりして、一貫性・保守性のある、エラーフリーの状態に保てます。
優れたツールを使う選択をする開発者が増えることを願っています。気軽に試してください。あなたのスタイルシートを改良できるでしょう。
（原文：Taking CSS Linting to the Next Level with Stylelint）
［翻訳：新岡祐佳子／編集：Livit］
