Browser
Node <– Node.js環境でも動く場合
…

? How would you like to define a style for your project? …

Use a popular style guide <– 有名なスタイルガイドを利用
Answer questions about your style
Inspect your JavaScript file(s)

? Which style guide do you want to follow? …

Airbnb: https://github.com/airbnb/javascript <– Airbnbスタイルガイド (厳格で有名)
Standard: https://github.com/standard/standard <– Standardスタイル (セミコロンなしなど)
Google: https://github.com/google/eslint-config-google <– Googleスタイル

? What format do you want your config file to be in? …

JavaScript <– .eslintrc.js を推奨
YAML
JSON
“`

このウィザードは非常に便利ですが、生成された設定ファイルを手動でカスタマイズする必要が出てくることがほとんどです。

主要な設定項目

.eslintrc.js (または他の形式) ファイルには、ESLintの挙動を制御するための様々なプロパティを定義します。主要なものをいくつか紹介します。

“`javascript
// .eslintrc.js の例
module.exports = {
// 1. 解析に使用するパーサーを指定
// デフォルトは Espree (標準JS)
parser: ‘@typescript-eslint/parser’, // TypeScriptの場合

// 2. パーサーのオプション
parserOptions: {
ecmaVersion: ‘latest’, // 使用するECMAScriptのバージョン
sourceType: ‘module’, // モジュール形式 (script or module)
ecmaFeatures: {
jsx: true, // JSXを許可する場合
},
project: ‘./tsconfig.json’, // TypeScriptの場合、tsconfig.jsonのパスを指定 (型情報が必要なルールのため)
},

// 3. コードが実行される環境
// グローバル変数を定義済みとみなす環境を指定
env: {
browser: true, // ブラウザ環境 (window, documentなど)
node: true, // Node.js環境 (process, requireなど)
es2021: true, // ES2021のグローバル変数と構文
},

// 4. 事前に定義されたグローバル変数 (envでカバーされないもの)
globals: {
$: ‘readonly’, // jQueryの $ は読み取り専用
MyGlobal: ‘writable’, // カスタムのグローバル変数
},

// 5. 使用するプラグイン
// lintルールや設定を提供する外部モジュール
plugins: [
‘@typescript-eslint’, // TypeScript関連のルール
‘react’, // React/JSX関連のルール
‘import’, // import文関連のルール
‘prettier’, // Prettierとの連携
],

// 6. 拡張設定 (既存の設定を継承)
// スタイルガイドやプラグイン推奨設定を利用する際に便利
extends: [
‘eslint:recommended’, // ESLintの基本的な推奨ルールセット
‘plugin:@typescript-eslint/recommended’, // TypeScriptの推奨ルールセット
‘plugin:@typescript-eslint/recommended-requiring-type-checking’, // 型情報が必要なTS推奨ルール
‘plugin:react/recommended’, // Reactの推奨ルールセット
‘airbnb-base’, // Airbnbスタイルガイド (JSXなし)
‘plugin:prettier/recommended’, // Prettier連携設定
],

// 7. 個別のルール設定
// extendsで継承したルールを上書きしたり、独自のルールを設定
rules: {
‘indent’: [‘error’, 2], // インデントはスペース2つでエラー
‘quotes’: [‘error’, ‘single’], // 引用符はシングルクォートでエラー
‘semi’: [‘error’, ‘always’], // セミコロンは常に必須でエラー
‘no-unused-vars’: ‘warn’, // 未使用変数は警告
‘no-console’: ‘warn’, // console.log は警告
‘react/react-in-jsx-scope’: ‘off’, // 新しいReactでは不要なルールをオフ
‘@typescript-eslint/explicit-function-return-type’: ‘off’, // 関数の戻り値の型推論を許可
‘@typescript-eslint/no-explicit-any’: ‘off’, // any型の使用を許可 (注意が必要)
},

// 8. 特定のファイルやディレクトリに対する設定の上書き
overrides: [
{
files: [‘.js’], // .js ファイルのみに適用
rules: {
‘@typescript-eslint/no-var-requires’: ‘off’, // JSファイルではrequireを許可
}
},
{
files: [‘.test.js’, ‘*.test.ts’], // テストファイルのみに適用
env: {
jest: true, // Jestのグローバル変数 (describe, itなど) を許可
},
rules: {
‘no-unused-expressions’: ‘off’, // テストにおける chai.expect(true).to.be.true; のような記述を許可
}
}
],

// 9. ESLintのバージョンに応じて共有設定を読み込むための設定
settings: {
react: {
version: ‘detect’, // インストールされているReactのバージョンを自動検出
},
// import/resolver など、プラグイン固有の設定
},
};
“`

各プロパティの詳細を見ていきましょう。

• parser: ESLintがコードを解析する際に使用するパーサーを指定します。JavaScriptの標準構文解析にはESLintデフォルトのEspreeが使われます。TypeScriptやJSXなど、標準JS以外の構文を解析したい場合は、対応するパーサーを指定する必要があります。TypeScriptの場合は@typescript-eslint/parserを指定します。
• parserOptions: パーサーの挙動を細かく設定します。使用するECMAScriptのバージョン (ecmaVersion)、モジュールの形式 (sourceType)、JSXの使用 (ecmaFeatures.jsx) などを指定します。TypeScriptプロジェクトで型情報に基づいたルールを使用する場合は、projectオプションでtsconfig.jsonへのパスを指定する必要があります。
• env: コードが実行される環境を定義します。これにより、その環境で事前に定義されているグローバル変数（例: ブラウザ環境ならwindow, document、Node.js環境ならprocess, require）をESLintがエラーとして報告しないようになります。es6, node, browser, jestなど、様々な環境が定義されています。
• globals: envで定義されていない、カスタムまたは特定のライブラリによって提供されるグローバル変数を定義します。値には 'writable' (書き込み可能) または 'readonly' (読み取り専用) を指定します。
• plugins: 使用するESLintプラグインを登録します。プラグインは、追加のLintルールセットや、特定の技術（例: React, Vue, Angular, Node.jsなど）に特化した機能を提供します。プラグイン名はプレフィックスなしで指定しますが、npmパッケージ名は通常 eslint-plugin- または @scope/eslint-plugin- となっています。例えば、eslint-plugin-reactをインストールした場合、ここにはreactと記述します。
• extends: 既存の設定セットを継承します。これは、他のプロジェクトが公開しているスタイルガイド（例: Airbnb, Google, Standard）や、プラグインが提供する推奨設定（例: eslint:recommended, plugin:@typescript-eslint/recommended）を簡単に適用できる便利な方法です。複数の設定をリスト形式で指定でき、後に記述された設定が前の設定を上書きします。
• rules: 個別のLintルールを設定します。extendsで継承したルールを上書きしたり、独自のルールを追加したりできます。ルールの設定は 'rule-name': 'severity' または 'rule-name': ['severity', options] の形式で行います。severityは 'off' (ルール無効), 'warn' (警告), 'error' (エラー) のいずれかです。'error'に設定すると、Lintエラーが発生した場合にESLintの実行が終了コード1で終了し、CIなどでビルド失敗の原因となります。optionsはルールによって異なり、配列形式で指定します。
• overrides: 特定のファイルパターンに対して、他の設定を上書きすることができます。例えば、テストファイルでは特定のグローバル変数（describe, itなど）を許可したり、Node.jsのサーバーサイドファイルではブラウザAPI関連のルールを無効にしたりする場合に便利です。
• settings: プラグインなどが追加の設定情報を読み込むために使用します。例えば、eslint-plugin-reactはsettings.react.versionを見て、どのバージョンのReactに対応したLintチェックを行うかを決定します。

.eslintignore による除外設定

Lintチェックから特定のファイルやディレクトリを除外したい場合は、プロジェクトのルートディレクトリに .eslintignore ファイルを作成します。このファイルには、Gitの .gitignore と同じ形式で無視したいパスを記述します。

例:

“`

ビルド成果物

dist/
build/

Node.jsの依存関係

node_modules/

設定ファイルなど

*.config.js
gulpfile.js
webpack.config.js

特定のディレクトリ

scripts/vendor/

特定のファイル

src/legacy/old-code.js
“`

node_modules/ やドットファイル/ディレクトリは、デフォルトで無視されますが、明示的に記述しておくと分かりやすいでしょう。

TypeScriptでの設定のポイント

TypeScriptプロジェクトでESLintを効果的に使うためには、以下の点が重要です。

1. パーサー: @typescript-eslint/parser を指定します。
2. プラグイン: @typescript-eslint を登録します。
3. extends: plugin:@typescript-eslint/recommended および plugin:@typescript-eslint/recommended-requiring-type-checking を継承することを強く推奨します。これにより、TypeScriptの特性を活かした多くの有用なルールが有効になります。
4. parserOptions.project: recommended-requiring-type-checking のルールを使うには、このオプションでtsconfig.jsonのパスを指定する必要があります。これにより、ESLintはTypeScriptコンパイラと同じように型情報を利用できるようになります。
5. 互換性のないルールの無効化: ESLintにはTypeScriptと相性の悪い、あるいはTypeScriptが提供する機能と重複するルールがいくつかあります。plugin:@typescript-eslint/recommended などを使うと自動的に適切なルールが無効化されますが、手動で設定する場合は注意が必要です（例: no-unused-vars の代わりに @typescript-eslint/no-unused-vars を使うなど）。

例えば、TypeScriptプロジェクト向けのシンプルな .eslintrc.js は以下のようになります。

javascript
module.exports = {
parser: '@typescript-eslint/parser',
parserOptions: {
project: './tsconfig.json', // プロジェクトに合わせてパスを調整
sourceType: 'module',
},
env: {
browser: true,
node: true,
es2021: true,
},
plugins: [
'@typescript-eslint',
],
extends: [
'eslint:recommended',
'plugin:@typescript-eslint/recommended',
'plugin:@typescript-eslint/recommended-requiring-type-checking',
],
rules: {
// 必要に応じて個別のルールを上書き
'@typescript-eslint/no-explicit-any': 'warn', // any型の使用は警告にする
},
};

このように、設定ファイルを適切に記述することで、ESLintはプロジェクトのコードベースに対して期待通りのLintチェックを行うことができるようになります。

ESLintの実行：CLIとオプション

設定ファイルが準備できたら、いよいよESLintを実行してコードをチェックします。ESLintは、Node.jsの環境でコマンドラインインターフェース（CLI）として実行するのが最も一般的です。

プロジェクトのルートディレクトリで、パッケージマネージャーのnpx（またはyarn dlx, pnpm dlx）を使ってESLintコマンドを実行できます。これにより、グローバルインストールすることなく、プロジェクトローカルにインストールされたESLintを実行できます。

基本的な実行コマンド

プロジェクトのすべてのJavaScript/TypeScriptファイルをチェックするには、ソースコードのディレクトリを指定してESLintを実行します。一般的なソースコードディレクトリは src や lib などです。

“`bash

src ディレクトリ内の全ての .js, .jsx, .ts, .tsx ファイルをチェックする場合

npx eslint src/

現在のディレクトリおよびサブディレクトリ内の全ての対応ファイルをチェックする場合

npx eslint .
“`

デフォルトでは、ESLintは設定ファイル (.eslintrc.*) をプロジェクトルートから探し、その設定に従って指定されたファイルパターンにマッチするファイルをチェックします。

よく使うコマンドオプション

ESLint CLIには様々なオプションがあります。よく使うものをいくつか紹介します。

• --fix: ESLintが検出した問題のうち、自動修正可能なものを修正します。コーディングスタイルの問題（インデント、スペース、セミコロンなど）の多くはこのオプションで修正できます。

  bash
npx eslint src/ --fix
  このオプションは非常に便利で、Lintエラーを手動で修正する手間を大幅に省くことができます。フォーマッター（Prettierなど）と連携する場合も、この--fixオプションが重要な役割を果たします。

• --config <path>: デフォルトの設定ファイル (.eslintrc.*) 以外のファイルを指定して実行します。

  bash
npx eslint src/ --config .eslintrc.backend.js

• --ignore-path <path>: デフォルトの無視ファイル (.eslintignore) 以外のファイルを指定します。

  bash
npx eslint src/ --ignore-path .gitignore

• --ext <.ext,...>: チェックするファイルの拡張子を指定します。デフォルトは .js, .jsx, .mjs, .cjs です。TypeScriptファイルをチェックするには .ts, .tsx を追加する必要があります。設定ファイルのparserOptions.ecmaFeatures.jsxやparser:@typescript-eslint/parserと組み合わせて使用します。

  bash
npx eslint src/ --ext .js,.jsx,.ts,.tsx
  ただし、ESLint 8以降では、特に指定がなければ自動的に適切な拡張子を判断してチェックすることが多いです。また、設定ファイルでoverridesを使ってファイルタイプごとにパーサーなどを指定している場合は、このオプションは不要な場合があります。

• --print-config <file>: 指定されたファイルに適用される最終的な設定内容（extendsで継承されたルールやプラグイン設定を全てマージしたもの）を表示します。設定が複雑になった場合に、意図通りに設定が適用されているかデバッグするのに非常に役立ちます。

  bash
npx eslint --print-config src/index.ts

• --rule '<rule-name>: ["severity", options]': 設定ファイルを使わず、コマンドラインで一時的にルールを設定して実行します。通常は設定ファイルで管理するためあまり使いませんが、特定のルールを試したい場合に便利です。

  bash
npx eslint src/index.js --rule 'no-console: "off"'

• --no-eslintrc: 設定ファイルを読み込まずに実行します。

• --no-ignore: .eslintignore ファイルやデフォルトの無視設定を無視して実行します。

• --quiet: 警告 (warn) を表示せず、エラー (error) のみを表示します。CIなどでエラーだけをチェックしたい場合に便利です。

npm scriptsへの登録

開発ワークフローの中でESLintを簡単に実行できるように、package.json の scripts にESLintコマンドを登録するのが一般的です。

json
{
"name": "my-project",
"version": "1.0.0",
"scripts": {
"lint": "eslint src/**/*.{js,jsx,ts,tsx}", // globパターンでチェック対象を指定
"lint:fix": "eslint src/**/*.{js,jsx,ts,tsx} --fix"
},
"devDependencies": {
"eslint": "^8.0.0",
"@typescript-eslint/parser": "^5.0.0",
"@typescript-eslint/eslint-plugin": "^5.0.0",
"glob": "^7.2.0" // globパターンを使う場合
}
}

このように設定しておけば、ターミナルで npm run lint や npm run lint:fix と実行するだけで、簡単にESLintを実行できます。ファイルパスの指定には、シェルやglobパッケージでサポートされているglobパターン（例: src/**/*.{js,jsx,ts,tsx} は src ディレクトリ以下の全てのサブディレクトリにある .js, .jsx, .ts, .tsx ファイルにマッチします）を使うと便利です。

CLIからの実行は、単発のチェックや自動修正、CIパイプラインでの実行などに適しています。しかし、開発中にリアルタイムでフィードバックを得るためには、エディタとの連携が不可欠です。これについては後述します。

ESLintとTypeScript：型情報を活用した強力なLinting

前述の通り、TypeScriptプロジェクトでは、ESLintと@typescript-eslint関連パッケージを組み合わせて使用するのが現在の標準的なプラクティスです。この組み合わせの最大のメリットは、TypeScriptの持つ「型情報」を利用したLintチェックが可能になる点です。

通常のJavaScriptのLintingは、コードの構文ツリー（AST）だけを見て判断しますが、TypeScriptの場合はコンパイラが生成する型情報も利用できます。これにより、以下のような、型システムに依存するより高度で正確なチェックが可能になります。

• 存在しないプロパティへのアクセス: オブジェクトに存在しないプロパティにアクセスしようとしている場合にエラーを出す。
• 型の不一致: 関数の引数や変数への代入などで、期待される型と実際の型が一致しない場合に警告/エラーを出す。
• 使用されていない変数/プロパティ/関数: TypeScriptコンパイラと同様に、実際に使用されていない定義を検出する。
• 型アサーションの制限: as any のような型アサーションの乱用を防ぐ。
• その他、型安全性を損なう可能性のあるパターン: 例えば、危険なOptional Chainingの使い方など。

@typescript-eslint/eslint-plugin の主要なルール例

@typescript-eslint/eslint-plugin には、TypeScriptコードの品質を高めるための数多くのルールが含まれています。その中でも、特に重要でよく使われるルールをいくつか紹介します。

• @typescript-eslint/explicit-function-return-type: 関数の戻り値の型注釈を必須にします（ただし、推論可能な場合は不要とするオプションもあります）。型を明示することで、コードの意図を明確にし、予期せぬバグを防ぎます。多くのプロジェクトで 'off' に設定されることも多いですが、プロジェクトの方針によります。
• @typescript-eslint/no-explicit-any: any 型の使用を制限します。any はTypeScriptの型チェックを無効化してしまうため、可能な限り避けるべきです。このルールを 'warn' や 'error' に設定することで、any の乱用を防ぎ、型安全性を保つことができます。
• @typescript-eslint/no-unused-vars: 使用されていない変数を検出します。ESLintの組み込みルールno-unused-varsのTypeScript対応版です。TypeScriptの機能（型パラメータなど）を正しく理解して検出します。
• @typescript-eslint/no-unsafe-assignment, @typescript-eslint/no-unsafe-call, @typescript-eslint/no-unsafe-member-access, @typescript-eslint/no-unsafe-return: any 型の値が絡む unsafe な操作（代入、関数呼び出し、プロパティアクセス、戻り値）を検出します。これらのルールは recommended-requiring-type-checking に含まれており、型安全性を高める上で非常に強力です。
• @typescript-eslint/restrict-plus-operands, @typescript-eslint/restrict-template-expressions: + 演算子やテンプレートリテラルで文字列以外の型を混ぜて使用することを制限します。これにより、予期せぬ型変換によるバグを防ぎます。これらのルールも型情報が必要です。
• @typescript-eslint/no-floating-promises: Promiseを await なしで呼び出し、その結果を処理していない場合に警告を出します。これにより、エラーハンドリング漏れや競合状態を防ぎます。型情報が必要です。

これらのルールを使うことで、TypeScriptの型システムが提供する安全性を最大限に引き出し、JavaScriptだけでは難しかった種類のバグを開発段階で発見できるようになります。

TSLintからの移行

もしあなたが既存のTSLintを使っているプロジェクトをESLintに移行する場合、いくつかの手順が必要です。

1. @typescript-eslint/parser と @typescript-eslint/eslint-plugin をインストールします。
2. .eslintrc.* ファイルを作成し、上記パッケージを使った設定を記述します。
3. TSLintの設定ファイル (tslint.json) のルールをESLintのルールにマッピングします。tslint-to-eslint-config のような自動変換ツールが役立ちます。
4. ESLintを実行し、TSLintでの指摘と同等、あるいはそれ以上の指摘が得られるか確認しながら設定を調整します。
5. TSLint関連のパッケージをアンインストールし、TSLintの設定ファイルを削除します。

TSLintからの移行は手間がかかる作業ですが、長期的に見ればESLintに統一することでツールの管理が楽になり、最新のLint機能を活用できるようになります。

TypeScriptプロジェクトにおけるESLintは、単なるコーディングスタイルの強制にとどまらず、コードの「正確性」や「安全性」を高めるための強力なツールとなります。型情報を活用したLintingは、TypeScriptを採用する大きなメリットの一つと言えるでしょう。

人気のプラグインと設定：より便利に、より強力に

ESLintの魅力の一つは、その拡張性の高さです。様々なコミュニティや企業によって開発されたプラグインを利用することで、特定のフレームワークやライブラリに特化したルールを追加したり、他の開発ツールと連携させたりすることができます。また、多くの開発チームが公開している「スタイルガイド」をextendsで継承することで、ゼロからルールを設定する手間を省き、広く受け入れられているコーディング規約を簡単に採用できます。

Prettierとの連携

ESLintと並んで、コード品質向上に広く使われているツールに「Prettier」があります。Prettierは「フォーマッター」であり、コードの書き方（インデント、スペース、改行、セミコロンなど）を自動で整形することに特化しています。一方、ESLintはスタイルの整形だけでなく、構文エラーや潜在的な問題の検出、コード構造に関するルール（未使用変数、複雑すぎる関数など）のチェックも行います。

両者は目的が異なりますが、一部の機能（例えばインデントやセミコロンの有無に関するルール）で重複または競合することがあります。両方を併用する場合、通常は以下のような役割分担を行います。

• Prettier: コードの見た目（インデント、スペース、改行、引用符、セミコロンなど）に関するルールを全て担当し、自動で整形する。
• ESLint: コードの構造や潜在的な問題に関するルール（未使用変数、特定の構文の使用禁止、命名規則など）を担当する。スタイリングに関するESLintルールは無効化する。

この役割分担を実現するために、eslint-config-prettier と eslint-plugin-prettier という二つのプラグインが利用されます。

1. eslint-config-prettier: ESLintのスタイリングに関するルールを全て無効化する設定を提供します。これを extends の最後に記述することで、他の extends や rules で設定されたスタイリングルールがPrettierと競合しないようにします。
2. eslint-plugin-prettier: PrettierをESLintのルールとして実行できるようにします。これにより、eslint --fix コマンドでPrettierによる整形も同時に行えるようになります。

インストール：
“`bash
npm install –save-dev prettier eslint-config-prettier eslint-plugin-prettier

または yarn add –dev …

または pnpm add –dev …

“`

.eslintrc.js の設定例：
“`javascript
module.exports = {
// … その他の設定 (parser, parserOptions, env, plugins, rules など)

extends: [
// … 他のスタイルガイドや推奨設定 (例: airbnb, recommended, typescript-recommended など)

'plugin:prettier/recommended', // これを一番最後に記述する！
// 'plugin:prettier/recommended' は以下のショートカットです:
// - 'eslint-config-prettier' を extends する
// - 'eslint-plugin-prettier' を plugins に登録する
// - 'prettier/prettier' ルールを 'error' に設定する (これによりPrettierの整形ルール違反がESLintエラーになる)

],

rules: {
// ‘plugin:prettier/recommended’ が styling ルールを無効化するので、
// ここでは styling 以外のルールのみを定義・上書きするのが望ましい。
‘no-unused-vars’: ‘warn’,
‘no-console’: ‘warn’,
// 例えば、インデントに関するルール ( ESLint 組み込みの ‘indent’ ) は記述しない。
// もし記述してしまっても、’plugin:prettier/recommended’ によって無効化される。
},
};
“`

plugin:prettier/recommended を使うことで、PrettierとESLintの連携が非常に簡単になります。Lintエラーの中にPrettierによる整形が必要な箇所も含まれるようになり、npx eslint --fix を実行するだけで、Lintエラーの修正とコード整形が同時に行われます。

さらに、VS Codeなどのエディタでは、保存時に自動的にPrettierで整形し、ESLintでチェック・修正を行う設定を有効にすることで、開発体験を大幅に向上させることができます。

フレームワーク・ライブラリ特化型プラグイン

特定のフレームワークやライブラリを使用している場合、それらに特化したLintルールが必要になります。

• React: eslint-plugin-react および eslint-plugin-react-hooks

  • JSX構文のチェック。
  • React Hooksのルール（依存配列のチェックなど）。
  • コンポーネントに関するベストプラクティスの強制。
  • extends: ['plugin:react/recommended', 'plugin:react-hooks/recommended'] を使うことが多いです。
  • settings.react.version の設定が必要です（'detect' が便利）。

• Vue.js: eslint-plugin-vue

  • .vue ファイルのテンプレート、スクリプト、スタイルのチェック。
  • Vueのディレクティブやコンポーネントに関するルール。
  • extends: ['plugin:vue/vue3-recommended'] など（Vueのバージョンによる）を使うことが多いです。

• Angular: @angular-eslint/builder, @angular-eslint/eslint-plugin, etc.

  • Angularプロジェクト向けのESLint設定。
  • @angular-eslint/recommended や @angular-eslint/template/recommended などの extends を使います。

• Import: eslint-plugin-import

  • import/export 構文の静的解析。
  • 解決できないパス、循環参照、未使用のエクスポートなどを検出。
  • インポート文の順番やグループ化に関するスタイリングルールも提供（Prettierと連携する場合はスタイリングルールはオフにすることが多い）。
  • extends: ['plugin:import/recommended'] を使うことが多いです。TypeScriptプロジェクトでは plugin:import/typescript も追加します。

これらのプラグインを利用することで、使用している技術スタックに特化した強力なLintチェックを行うことができます。

有名なスタイルガイドの設定

自分でゼロからLintルールを設定するのは大変です。そこで、多くの開発チームや企業が公開している標準的なスタイルガイドをextendsで継承するのが一般的です。

• Airbnb JavaScript Style Guide:
  • 非常に網羅的で厳格なスタイルガイドとして有名です。
  • eslint-config-airbnb (React含む) または eslint-config-airbnb-base (Reactなし) をインストールし、extends: ['airbnb-base'] のように設定します。
  • 依存パッケージが多い点に注意が必要です。
• Standard JavaScript Style:
  • セミコロンなし、末尾カンマなしなど、特徴的なスタイルを持つガイドです。設定がシンプルで、すぐに使い始められる点が魅力です。
  • eslint-config-standard (JSのみ) または eslint-config-standard-with-typescript (TS含む) をインストールし、extends: ['standard'] のように設定します。
• Google JavaScript Style Guide:
  • Googleが内部で使用しているスタイルガイドです。Airbnbほど厳格ではないという意見もあります。
  • eslint-config-google をインストールし、extends: ['google'] と設定します。

これらのスタイルガイドをベースに設定し、必要に応じて個別のルールを上書きすることで、プロジェクトに合ったスタイルを効率的に構築できます。

プラグインやスタイルガイドを組み合わせることで、ESLintは単なる構文チェッカーから、特定の技術スタックやチーム規約に最適化された強力なコード品質管理ツールへと進化します。

ESLintのルールを理解する：カスタマイズと無効化

ESLintの設定の中心となるのが「ルール」です。各ルールは、特定のコードパターンに対して警告やエラーを発行するかどうかを定義します。ESLintには数百もの組み込みルールがあり、さらにプラグインによって多数のルールが追加されます。

ルールの構造と設定方法

.eslintrc.* ファイルの rules セクションで、個別のルールを設定します。設定はオブジェクト形式で、キーがルール名、値がルールの設定です。

ルールの設定値は、以下のいずれかの形式をとります。

1. 'off' または 0: ルールを無効にする。
2. 'warn' または 1: ルール違反を警告として報告する（ESLintの終了コードは0）。
3. 'error' または 2: ルール違反をエラーとして報告する（ESLintの終了コードは1）。

例:

javascript
rules: {
'no-unused-vars': 'warn', // 未使用変数は警告
'no-console': 'off', // console.log はチェックしない
'semi': 'error', // セミコロンなしはエラー
}

多くのルールは、 severity の他にオプションを指定できます。オプションは配列形式で、最初の要素が severity、それ以降の要素がオプションとなります。オプションの種類や数はルールによって異なります。

例:

javascript
rules: {
'indent': ['error', 2, { 'SwitchCase': 1 }], // インデントはスペース2つでエラー。switch文のcaseは1段階インデント。
'quotes': ['error', 'single', { 'allowTemplateLiterals': true }], // 引用符はシングルクォートでエラー。ただしテンプレートリテラルは許可。
'max-len': ['warn', { 'code': 120, 'ignoreComments': true }], // 1行の文字数が120を超えたら警告。コメントは無視。
}

ルールの詳細な使い方やオプションについては、ESLintの公式ドキュメントを参照するのが最も確実です。

よく使う/役立つルール例 (JavaScript & TypeScript)

ESLintには非常に多くのルールがありますが、ここでは特にJavaScript/TypeScriptプロジェクトでよく使われる、あるいは知っておくと役立つルールをいくつかピックアップして紹介します。

JavaScript (ESLint 組み込みルール)

• no-unused-vars: 使用されていない変数を検出します。コードの整理に役立ちます。
• no-console: console.log などの使用を制限します。本番環境にデバッグコードが残るのを防ぎます。
• no-alert, no-prompt: alert, prompt の使用を制限します。
• no-undef: 未定義の変数使用を検出します。スペルミスなどによる参照エラーを防ぎます。
• eqeqeq: == や != の代わりに === や !== の使用を強制します。予期せぬ型変換によるバグを防ぎ、厳密な比較を推奨します。
• no-plusplus: ++, -- 演算子の使用を制限します。コードの可読性を高めるため、+= 1 や -= 1 を推奨するスタイルで使われます。
• camelcase: 変数名、関数名、プロパティ名などを camelCase に強制します。
• quotes: 引用符の種類（シングルかダブルか）を強制します。
• semi: セミコロンの有無を強制します。
• indent: インデントの種類（タブかスペースか）と幅を強制します。
• max-len: 1行の最大文字数を制限します。コードの可読性を高めます。
• complexity: 関数の循環的複雑度を制限します。複雑すぎる関数は分割を検討すべきです。
• max-depth: ブロックのネストの深さを制限します。ネストが深いコードは可読性が低下しがちです。
• max-params: 関数の引数の数を制限します。引数が多い関数は設計を見直す必要があるかもしれません。
• max-statements: 関数内のステートメントの数を制限します。関数が長すぎる場合に警告します。

TypeScript (@typescript-eslint プラグインのルール)

• @typescript-eslint/explicit-function-return-type: 関数の戻り値の型注釈を必須にする（設定による）。
• @typescript-eslint/no-explicit-any: any 型の使用を制限する。
• @typescript-eslint/no-unused-vars: TypeScript対応の未使用変数チェック。
• @typescript-eslint/no-non-null-assertion: ! (non-null assertion operator) の使用を制限する。安易な使用は実行時エラーにつながる可能性があります。
• @typescript-eslint/no-unsafe-* (assignment, call, member-access, return): any 型が絡むunsafeな操作を検出する。
• @typescript-eslint/await-thenable: await可能なPromise以外の値をawaitしていないかチェックする。
• @typescript-eslint/no-floating-promises: Promiseをawaitせずに結果を無視していないかチェックする。

これらのルールは、コードのスタイルだけでなく、潜在的なバグや設計上の問題を検出するのに役立ちます。プロジェクトの特性に合わせて、必要なルールを選択し、適切に設定することが重要です。

特定の行/ファイルでルールを無効にする (eslint-disable)

ESLintのルールは非常に便利ですが、ごく稀に、どうしても特定の行やブロック、あるいはファイル全体で特定のルールを無効にしたい場合があります。例えば、レガシーコードや、意図的に特定のパターンを使用している場合などです。

このような場合、特別なコメント (eslint-disable) を使用して、一時的にルールを無効にすることができます。

• ファイル全体で無効にする: ファイルの先頭に記述します。

  javascript
/* eslint-disable */
// このファイル全体で全てのESLintルールが無効になります

  javascript
/* eslint-disable no-console, no-unused-vars */
// このファイル全体で no-console と no-unused-vars ルールが無効になります

• 特定の行で無効にする: 対象の行の末尾に記述します。

  javascript
console.log('デバッグ情報'); // eslint-disable-line no-console

• 特定のブロックで無効にする: ブロックの開始前に eslint-disable、終了後に eslint-enable を記述します。

  “`javascript
  / eslint-disable no-alert /
  function showWarning(message) {
  alert(message); // ここでは no-alert ルールは無効
  }
  / eslint-enable no-alert /

  alert(‘この行では no-alert ルールが有効です’); // この行はエラーになる可能性がある
  “`

eslint-disable コメントは便利な反面、濫用するとLintのメリットを損ないます。可能な限りルールを無効にするのではなく、ESLintの指摘を修正したり、設定を調整したりすることを検討すべきです。やむを得ず使用する場合は、なぜそのルールを無効にするのかを明確にするコメントを併記することを推奨します。

ESLintのルールを理解し、適切に設定・カスタマイズすることで、プロジェクトのコードベースに求められる品質レベルを維持・向上させることができます。

ESLintと開発ワークフロー：自動化による効率向上

ESLintは、開発プロセスの様々な段階に組み込むことで、その効果を最大限に発揮します。手動でLintコマンドを実行するだけでなく、以下の方法で自動化することで、開発者は常に高品質なコードを維持しながら効率的に作業を進めることができます。

エディタ連携：リアルタイムなフィードバック

最も効果的なESLintの活用方法の一つは、開発中にエディタ上でリアルタイムにLintのフィードバックを得ることです。主要なモダンエディタやIDEは、ESLintの連携機能を提供しています。

• VS Code: 公式の ESLint 拡張機能 が提供されています。これをインストールすると、開いているファイルのコードに対してESLintがバックグラウンドで実行され、問題箇所が波線などでハイライト表示されます。マウスオーバーで問題の詳細を確認でき、多くの場合、クイックフィックス機能（電球アイコンやAlt+Enter）で自動修正することも可能です。設定で「保存時にESLintを自動実行し修正する」を有効にしておくと、ファイルを保存するたびにLintチェックと自動修正が行われ、常にクリーンな状態を保てます。

• WebStorm / IntelliJ IDEA: これらのIDEはESLintを標準でサポートしています。設定画面でESLintを有効にし、Node.jsの実行パスや設定ファイルのパスを指定することで、VS Codeと同様にリアルタイムのチェックや自動修正が利用できます。

• その他のエディタ: Atom, Sublime Text, Vimなど、多くのエディタ向けにESLint連携のプラグインが存在します。

エディタ連携により、Lintエラーや警告を早期に発見し、その場で修正できるため、後からまとめて修正するよりもはるかに効率的です。開発者はLintの問題に煩わされることなく、コーディングに集中できます。

Gitフックとの連携：コミット前の自動チェック

コードの品質をチーム全体で維持するには、不正なコードがリポジトリにプッシュされるのを防ぐ仕組みが有効です。Gitの「クライアントサイドフック」を利用すると、commit や push といった特定のGit操作の前に任意のスクリプトを実行できます。

特に pre-commit フックは、コミットの直前に実行されるため、コミットされるコードに対してLintチェックやフォーマットを強制するのに最適です。もしLintエラーがあればコミットを中断させ、修正を促すことができます。

Gitフックを手動で設定するのは少し手間がかかりますが、「Husky」や「lint-staged」といったツールを使うと簡単に実現できます。

• Husky: Gitフックの設定を package.json または専用の設定ファイル (.husky/) で管理できるようにするツールです。
• lint-staged: Gitのステージングエリアにあるファイル（つまり、これからコミットしようとしている変更ファイル）に対してのみコマンドを実行できるツールです。ESLintはプロジェクト全体を実行すると時間がかかることがありますが、lint-stagedを使えば変更ファイルだけを対象にできるため、コミットの待ち時間を短縮できます。

典型的な設定手順：

1. Huskyとlint-stagedをインストールします。
   bash
npm install --save-dev husky lint-staged
# または yarn add --dev ... / pnpm add --save-dev ...
2. package.json に Huskyとlint-stagedの設定を追加します（または、Huskyの対話式セットアップを実行します）。
   json
{
// ...
"scripts": {
// ...
"prepare": "husky install" // このスクリプトは npm install 後に自動実行され、.husky ディレクトリを作成・設定します
},
"husky": {
"hooks": {
"pre-commit": "lint-staged" // コミット前に lint-staged を実行
}
},
"lint-staged": {
"src/**/*.{js,jsx,ts,tsx}": [ // ステージングエリアにあるこれらのファイルに対して...
"eslint --fix", // ESLintを --fix オプション付きで実行
"prettier --write", // Prettierでフォーマット (併用する場合)
"git add" // ESLint/Prettierによる修正を再度ステージング
]
}
}
3. npm install を実行すると、prepare スクリプトによって .husky ディレクトリが作成され、pre-commit フックが設定されます。

これで、git commit を実行するたびに、ステージングエリアにあるJavaScript/TypeScriptファイルに対してESLint (--fix 付き) が実行されるようになります。もしESLintのエラー（自動修正できないもの）があれば、コミットは失敗し、修正が促されます。

この仕組みを導入することで、Lintルールに違反したコードがリポジトリに混入することを防ぎ、コードベース全体の品質を高く保つことができます。

CI/CDパイプラインへの組み込み

開発フローのさらに上流、Continuous Integration（CI）やContinuous Deployment（CD）パイプラインにもESLintを組み込むべきです。プルリクエストが作成された時や、コードがメインブランチにマージされる前に、自動的にLintチェックを実行し、エラーがあればビルドを失敗させるように設定します。

CI環境でのESLint実行は、ローカルでのLintチェックを補完する役割を果たします。特に、ローカル環境の設定漏れや、フックをスキップしてコミットされた場合でも、CI環境で必ず品質チェックが行われるようにすることで、より堅牢な品質保証体制を構築できます。

CIの設定ファイル（例: GitHub Actions, GitLab CI, CircleCI, Jenkinsなど）に、ESLint実行ステップを追加します。

例 (GitHub Actions):

“`yaml
name: CI

on:
push:
branches:
– main
pull_request:
branches:
– main

jobs:
lint:
runs-on: ubuntu-latest
steps:
– uses: actions/checkout@v3
– uses: actions/setup-node@v3
with:
node-version: ’18’
cache: ‘npm’ # または yarn, pnpm
– run: npm ci # 依存関係をインストール
– run: npm run lint # package.json に定義した lint スクリプトを実行
“`

CI環境では、自動修正 (--fix) オプションは通常使いません。エラーがある場合にビルドを失敗させることで、開発者にローカルでの修正を促します。package.json の lint スクリプトは、修正オプションなしで設定するのが一般的です。

json
"scripts": {
"lint": "eslint src/**/*.{js,jsx,ts,tsx}",
"lint:fix": "eslint src/**/*.{js,jsx,ts,tsx} --fix"
}

エディタ連携、Gitフック、CI/CDパイプラインへの組み込みは、ESLintを単なる開発ツールから、開発チーム全体の品質管理プロセスの中核へと昇格させます。これらの自動化によって、コード品質の維持が開発者の負担にならず、自然な習慣として定着するようになります。

ESLintの応用とトラブルシューティング

ESLintを大規模なプロジェクトや複雑な環境で使用する場合、さらに応用的な設定や、時折遭遇する問題への対応が必要になることがあります。

モノレポでの設定管理

yarn workspaces や pnpm workspaces、Nx、Lerna といったツールを使ったモノレポ（単一のリポジトリで複数のパッケージを管理する構成）では、ESLintの設定管理が課題となることがあります。

モノレポにおけるESLint設定のアプローチにはいくつかあります。

1. ルートに一元管理: モノレポのルートに単一の .eslintrc.js を置き、overrides を駆使してパッケージごとに異なる設定を適用します。シンプルですが、overrides が複雑になりがちです。
2. パッケージごとに設定: 各パッケージディレクトリに個別の .eslintrc.js を置きます。管理は分散しますが、パッケージ固有の設定がしやすくなります。ルートの設定を継承することも可能です。
3. 共有設定パッケージ: 共通のESLint設定を独立したnpmパッケージとして切り出し、各パッケージでその設定を extends します。設定の再利用性が高まりますが、セットアップの手間がかかります。

どの方法を採用するかは、モノレポの構造やパッケージ間の依存関係、チームの運用方針によって異なります。特にTypeScriptプロジェクトで型情報に基づいたルールを使う場合、parserOptions.project の設定がパッケージごとに異なる tsconfig.json を参照する必要があるため、設定が少し複雑になる傾向があります。

パフォーマンス最適化

大規模なコードベースに対してESLintを実行すると、時間がかかることがあります。パフォーマンスを改善するためのアプローチをいくつか紹介します。

• 対象ファイルの限定: lint-staged を使って変更ファイルのみを対象とする、またはCLIで特定のディレクトリやファイルのみを指定して実行します。
• キャッシュの利用: ESLintは --cache オプションを提供しています。一度チェックしたファイルで変更がない場合は、前回の結果を再利用することで高速化できます。CI環境などでも有効です。
  bash
npx eslint src/ --cache
• 型情報が必要なルールの適用範囲を絞る: @typescript-eslint/recommended-requiring-type-checking に含まれるルールは型チェックを行うため時間がかかります。これらのルールは、必要なファイル（例えば、テストファイルなどでは不要な場合も）にのみ適用するように overrides で調整することを検討します。
• ESLintの並列実行: ESLint自体はシングルスレッドですが、pnpm lint --parallel のように、パッケージマネージャーの機能や外部ツールを使って複数のESLintプロセスを並列実行することで全体の時間を短縮できる場合があります。
• .eslintignore の活用: 不要なファイルやディレクトリを明確に無視することで、ESLintの走査対象を減らします。

一般的なエラーと解決策

ESLintのセットアップ中に遭遇しやすい一般的なエラーと、その解決策のヒントです。

• eslint command not found: ESLintがプロジェクトローカルにインストールされている場合、npx eslint ... のようにnpx（またはyarn dlx, pnpm dlx）を使って実行する必要があります。グローバルインストールしている場合はパスが通っているか確認します。
• Parsing error: Invalid …: パーサーの設定が間違っているか、解析対象のコードがパーサーが対応していない構文を含んでいる可能性があります。TypeScriptなら @typescript-eslint/parser、JSXなら parserOptions.ecmaFeatures.jsx: true が正しく設定されているか確認します。
• Rule … is not found: 設定ファイルで指定しているルールが見つかりません。
  • ESLint組み込みルールの場合: ESLintのバージョンが古くないか確認します。
  • プラグインのルールの場合: そのプラグインが正しくインストールされ、設定ファイルの plugins に登録されているか確認します。ルール名のプレフィックス（例: @typescript-eslint/, react/）が正しいか確認します。
• Config for rule … is invalid: ルール設定のオプションに間違いがあります。公式ドキュメントでルールのオプションを確認します。
• You have used a rule which requires parserServices to be built…: @typescript-eslint の型情報が必要なルールを使おうとしていますが、parserOptions.project が正しく設定されていないか、tsconfig.json が見つからない、または解析に失敗している可能性があります。parserOptions.project のパスを確認し、tsconfig.json がESLintを実行する環境からアクセス可能か確認します。
• Ignoring file …: .eslintignore ファイルやデフォルト設定によってファイルが無視されています。意図通りか確認し、必要であれば .eslintignore を編集します。--no-ignore オプションで無視設定を一時的に無効にして確認することも可能です。

これらの問題に遭遇した際は、エラーメッセージをよく読み、ESLintの公式ドキュメントや関連プラグインのドキュメントを参照することが解決への近道です。また、npx eslint --print-config <file> コマンドは、特定のファイルにどのような設定が最終的に適用されているかを確認できるため、設定に関するデバッグに非常に役立ちます。

まとめ：ESLintで継続的なコード品質改善を

この記事では、JavaScript/TypeScriptプロジェクトのコード品質を向上させるためのESLintについて、その概要からインストール、設定、実行、TypeScriptとの連携、人気プラグイン、ルールのカスタマイズ、そして開発ワークフローへの組み込み方までを詳細に解説しました。

ESLintを導入し、開発プロセスに組み込むことのメリットを改めて振り返ってみましょう。

• コードの一貫性向上: プロジェクト全体で統一されたコーディングスタイルが強制され、コードが読みやすく、理解しやすくなります。
• バグの早期発見: 構文エラー、潜在的な実行時エラー、危険なパターンなどを開発の早い段階で検出できます。特にTypeScriptとの連携により、型に起因するバグも発見しやすくなります。
• 保守性の向上: 統一されたスタイルと少ないバグにより、コードの修正や機能追加が容易になります。
• 開発効率の向上: スタイルに関する指摘や簡単なミスの検出が自動化されるため、コードレビューの負荷が軽減され、開発者はより創造的な作業に集中できます。
• チーム開発の円滑化: コーディングスタイルに関する議論を減らし、チームメンバー間の認識齟齬を防ぎます。

ESLintは非常に柔軟なツールであり、プロジェクトの規模や特性、チームの文化に合わせて細かく設定を調整できます。はじめは基本的な推奨設定から導入し、徐々に必要なルールを追加したり、既存のルールをカスタマイズしたりしていくのが良いアプローチです。

ESLintは一度設定すれば終わりではありません。プロジェクトの進化、使用するライブラリやフレームワークの変更、ESLintや関連プラグインのバージョンアップなどに応じて、設定を見直し、メンテナンスしていくことが重要です。エディタ連携、Gitフック、CIパイプラインへの組み込みを徹底することで、コード品質の維持が開発者の負担ではなく、自然な習慣として開発フローに溶け込むようになります。

コード品質は、ソフトウェア開発の成功を支える基盤です。ESLintを効果的に活用し、常に高品質なコードを目指しましょう。この記事が、あなたのESLint導入と活用の一助となれば幸いです。