ESLintは、JavaScript・TypeScriptのソースコードを静的に解析してバグの種や規約違反を指摘するLinterです。2013年6月にニコラス・C・ザカス氏が公開しました。同氏は『JavaScript: The Good Parts』に並ぶ古典『Maintainable JavaScript』の著者で、Yahoo!時代に培ったコード品質管理のノウハウを反映したツールとして開発されました。JSHint・JSLintという先行ツールがあった中で「ルールごとに有効/無効を切り替えられ、プラグインで拡張できる」設計が決め手となり、現在はJavaScriptプロジェクトの99%が事実上採用する標準Linterとなっています。
この記事の目次
- ASTベースのルールエンジン
- JSLint・JSHintからの系譜
- プロジェクトでの導入形
- Prettierとの役割分担
- まとめ
ASTベースのルールエンジン
ESLintの中身は、まずソースコードをパーサーで抽象構文木（AST）に変換し、登録されたルール群がそのASTを走査しながら違反箇所を報告する、という構造になっています。デフォルトのespreeパーサーに加え、TypeScriptを扱う@typescript-eslint/parser、JSX対応のbabel-eslintなどを差し替えられるため、Vue・Svelte・GraphQLといったJS以外のテキストにも適用範囲を広げられます。ルールごとにerror/warn/offを設定できる粒度の細かさが、JSHintから乗り換える決定打になりました。
もう一つの強みが自動修正（autofix）機構です。クォートの統一・セミコロン補完・未使用import削除・配列の末尾カンマ追加といった機械的な修正は、--fixオプションで一括変換できます。プラグインを書けば自前ルールも自動修正に対応させられるため、社内コーディング規約の自動適用ツールとして導入する企業も少なくありません。VS CodeのESLint拡張機能と組み合わせれば、保存と同時にコードを整える運用が当たり前になりました。
JSLint・JSHintからの系譜
JavaScriptのLinter史は2002年、ダグラス・クロックフォード氏がJSLintを公開したところから始まりました。JSLintは作者の強い意見が直接ルール化されており「設定で挙動を変える発想がほぼない」スタイルだったため、現場の実情と合わない部分も多く、2010年にアントン・コヴァリョフ氏らがフォークして設定可能性を高めたのがJSHintです。
しかしJSHintも内部設計が古く、独自ルールの追加が困難でした。ニコラス・C・ザカス氏は2013年6月に「ASTで動き、ルールがプラグインとして外から差し込める」新しいLinterを「ESLint」として公開し、ES6（2015年）の急速な変化やReact／Vue／TypeScriptの台頭という時代背景に乗って一気に標準化されました。2018年前後にはAirbnb JavaScript Style GuideのESLint設定が事実上のスタイル基準として広まり、TypeScript対応の@typescript-eslintも安定して、現在のフロントエンドDXの土台として定着しています。
プロジェクトでの導入形
実際のプロジェクトでESLintは複数のレイヤで動きます。開発者の手元ではVS CodeやWebStormなどのIDE拡張が、ファイル保存時に違反を強調表示し--fixで直せる範囲を即時修正します。コミット直前にはhuskyとlint-stagedの組み合わせでpre-commit hookとして走らせ、規約違反のコードをそもそもコミットさせない運用が一般的です。GitHub ActionsやCircleCIではPull Requestごとのチェックジョブとして走り、レビュアーの負担を機械的に軽減します。
業務系のプロジェクトではeslint-plugin-securityでXSSや危険な正規表現を検出したり、eslint-plugin-jsx-a11yでアクセシビリティを担保したり、社内独自の命名規約をプラグイン化するケースも多いです。プラグインはnpmに公開された数千件のエコシステムがあり、Reactならeslint-plugin-react、Node.jsならeslint-plugin-n、テストファイル向けにはeslint-plugin-jestといった具合に、ほぼ全領域をカバーします。「コードの一貫性を仕組みで担保する」ためのデファクトインフラとして機能しています。
Prettierとの役割分担
ESLintを語るうえで欠かせないのが、後発のPrettierとの役割分担です。もともとESLintはコード整形（フォーマット）機能と論理チェック機能の両方を抱えていましたが、2017年にPrettierが登場してからは「フォーマットはPrettier、論理ルールはESLint」と明確に分業されるようになりました。整形ルールはeslint-config-prettierで無効化し、衝突を回避するのが定番設定です。
ESLintの役割は、未使用変数の検出・===の強制・no-unused-promisesといった「コードの正しさ」を担う仕事に絞られました。セキュリティやアクセシビリティの違反検出、Reactフックの規則遵守、TypeScriptの型を踏まえた高度なチェックなど、Prettierには真似できない領域で力を発揮します。両者を併用して「論理はESLint、見た目はPrettier」と分担する構成が、現在のJSプロジェクトのほぼ標準的なやり方となっています。
まとめ
ESLintは2013年にニコラス・C・ザカス氏が公開したJavaScript向けLinterで、ASTベースの拡張可能なルールエンジンを核とします。JSLint・JSHintの系譜を継ぎながら、プラグイン文化と自動修正で開発者体験を一新し、フロントエンドの標準ツールになりました。Prettierと役割を分担しつつ、論理的なコード品質を守る不可欠な存在として今も中心に居続けています。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント