ESLintには非常に多くの組み込みルールがあります。すべてのルールとそのオプションは、ESLintの公式ドキュメントで確認できます: https://eslint.org/docs/latest/rules/

extends でベースとなるスタイルガイドを適用し、rules でプロジェクト固有の要件やチームの好みに合わせて微調整するのが一般的な方法です。

3.3. env: 環境の指定

env プロパティは、コードが実行される環境をESLintに伝えます。これにより、その環境で定義されているグローバル変数（ブラウザの window や document、Node.jsの process や __dirname など）を未定義エラーとして報告しないようにします。

env プロパティの値はオブジェクトで、キーは環境名、値は true または false です。

一般的な環境:

• browser: ブラウザ環境（window, document, navigator など）
• node: Node.js環境（process, __dirname, module など）
• es6: ES6のグローバル変数や構文（Set, Map, Promise, 新しい静的メソッドなど）
• commonjs: CommonJSモジュール（require, module.exports など）
• jquery: jQueryのグローバル変数（$, jQuery）
• jest: Jestテストフレームワークのグローバル変数（describe, it, expect など）
• mocha: Mochaテストフレームワークのグローバル変数（describe, it, beforeEach など）
• jasmine: Jasmineテストフレームワークのグローバル変数
• cypress: Cypressテストフレームワークのグローバル変数
• serviceworker: Service Workerグローバル変数
• worker: Web Workerグローバル変数

例:

javascript
module.exports = {
env: {
browser: true, // ブラウザ環境を有効にする
node: true, // Node.js環境を有効にする
es2021: true // ECMAScript 2021のグローバル変数や構文を有効にする (es6, es2017などの代わりに推奨)
},
// ...その他の設定
};

es6 の代わりに es2017, es2020, es2021 などの特定のECMAScriptバージョンを指定することも可能です。これらは、そのバージョンで導入された新しいグローバル変数や構文（例: BigInt, globalThis）を認識させます。通常、最新のECMAScriptバージョンを指定しておけば問題ありません。

3.4. globals: グローバル変数の定義

env でカバーされないカスタムのグローバル変数や、特定のライブラリが定義するグローバル変数をESLintに知らせたい場合は、globals プロパティを使用します。

globals の値はオブジェクトで、キーはグローバル変数名、値はその変数に対する許可設定です。

• "writable" または "writeable": 変数への書き込みを許可する。
• "readonly" または "readable": 変数への書き込みを禁止する（読み取り専用）。
• "off": そのグローバル変数を許可しない（未定義エラーとして報告）。

例:

javascript
module.exports = {
// ... env など
globals: {
myGlobalVariable: 'readonly', // 'myGlobalVariable' は読み取り専用のグローバル変数
$: 'readonly', // '$' (jQueryなど) は読み取り専用のグローバル変数
React: 'readonly', // React (CDN経由などでグローバルに定義されている場合)
// 'writable' なグローバル変数が必要なケースは少ない
},
// ...その他の設定
};

通常、モダンなJavaScript開発では、モジュールシステムを使用するためグローバル変数を明示的に扱う機会は減りますが、レガシーコードや特定のライブラリを使用する際には必要になることがあります。

3.5. parser および parserOptions: パーサーの設定

ESLintはデフォルトでEspreeというパーサーを使用し、標準的なJavaScript構文を解析します。しかし、TypeScriptやJSX、Flowなどの標準JavaScriptにはない構文を使用する場合、ESLintにこれらの構文を理解させるために、別のパーサーを指定する必要があります。

• parser: 使用するパーサーのパッケージ名を指定します。
  • @babel/eslint-parser: Babelによってサポートされている構文（新しいECMAScriptの機能、JSX、Flowなど）を解析できます。
  • @typescript-eslint/parser: TypeScript構文を解析できます。TypeScriptプロジェクトではこれを使用します。
• parserOptions: パーサーの挙動を詳細に設定します。
  • ecmaVersion: 使用しているECMAScriptのバージョンを指定します (5, 6 (2015), 7 (2016), …, latest または特定の年 (2021, 2022など))。デフォルトは5です。latest を指定すると、ESLintがサポートする最新のECMAScriptバージョンを使用します。通常、latest または開発環境でサポートされている最新バージョンを指定します。
  • sourceType: モジュールの種類を指定します ("script" または "module")。import/export 文を使用している場合は "module"、それ以外は "script" を指定します。通常、現代のプロジェクトでは "module" です。
  • ecmaFeatures: 使用するECMAScriptの言語機能を有効/無効にします。
    • jsx: JSX構文を有効にする (true または false)。Reactなどで必要です。
    • globalReturn: グローバルスコープでの return を許可する。
    • impliedStrict: スクリプトのstrict modeを有効にする。
    • experimentalObjectRestSpread: オブジェクトのレスト/スプレッドプロパティを有効にする。 (ecmaVersion >= 2018 なら不要)

例 (React + ES Modules):

javascript
module.exports = {
// ... env など
parserOptions: {
ecmaVersion: 'latest', // 最新のECMAScriptバージョンを解析
sourceType: 'module', // ES Modules を使用
ecmaFeatures: {
jsx: true, // JSXを有効にする
},
},
// ...その他の設定
};

例 (TypeScript):

javascript
module.exports = {
// ... env など
parser: '@typescript-eslint/parser', // TypeScriptパーサーを指定
parserOptions: {
ecmaVersion: 'latest',
sourceType: 'module',
// TypeScript固有の設定 (tsconfig.jsonへのパスなど) が必要な場合もある
project: ['./tsconfig.json'], // @typescript-eslint/recommended-requiring-type-checking などで必要
},
plugins: [
'@typescript-eslint', // TypeScriptプラグインを有効にする
],
extends: [
'eslint:recommended',
'plugin:@typescript-eslint/recommended', // TypeScript推奨ルール
// 型情報が必要なより厳格なルールを使いたい場合
// 'plugin:@typescript-eslint/recommended-requiring-type-checking',
],
// ...その他の設定
};

TypeScriptプロジェクトの場合、@typescript-eslint/parser と @typescript-eslint プラグインは必須です。また、型情報を使った高度なルールを利用するには、parserOptions.project で tsconfig.json へのパスを指定する必要がある場合があります。

3.6. plugins: プラグインの利用

plugins プロパティは、ESLintの組み込みルールや設定だけではカバーできない特定のライブラリ、フレームワーク、あるいはドメイン固有のルールや環境をサポートするためのものです。プラグインは通常、追加のルール、推奨設定 (extends 経由で利用)、環境 (env 経由で利用)、そしてプロセッサー（非JavaScriptファイルからのコード抽出などに使用）を提供します。

plugins には、使用したいプラグイン名の配列を指定します。プラグイン名のプレフィックス eslint-plugin- は省略可能です。

例:

javascript
module.exports = {
// ... env, parserOptions など
plugins: [
'react', // eslint-plugin-react を使用
'jsx-a11y', // eslint-plugin-jsx-a11y を使用
'@typescript-eslint', // @typescript-eslint/eslint-plugin を使用
'import', // eslint-plugin-import を使用 (import/export 構文関連のルール)
],
extends: [
// プラグインが提供する推奨設定は extends で利用
'eslint:recommended',
'plugin:react/recommended',
'plugin:jsx-a11y/recommended',
'plugin:import/recommended',
// 他の extends 設定もここに追加
],
rules: {
// プラグインが提供する個別ルールは rules で設定
'react/jsx-uses-react': 'off', // 例: React 17+ で不要になったルールを無効化
'react/react-in-jsx-scope': 'off', // 例: React 17+ で不要になったルールを無効化
'jsx-a11y/anchor-is-valid': 'warn', // 例: 特定のルールレベルを変更
},
// ...その他の設定
};

プラグインを使用するには、まずnpmでインストールする必要があります（例: npm install --save-dev eslint-plugin-react）。

人気のあるプラグイン:

• eslint-plugin-react: ReactおよびJSX固有のルール。
• eslint-plugin-vue: Vue.js固有のルール。
• eslint-plugin-jsx-a11y: JSXにおけるアクセシビリティルール。
• eslint-plugin-import: ES Modulesのimport/export構文に関するルール。
• @typescript-eslint/eslint-plugin: TypeScript固有のルール。
• eslint-plugin-jest: Jestテストに関するルール。
• eslint-plugin-cypress: Cypressテストに関するルール。
• eslint-plugin-prettier: ESLintからPrettierを実行するためのプラグイン（後述）。

3.7. settings: プラグインへの共有設定

settings プロパティは、ESLintの設定オブジェクト全体で共有される情報を指定するために使用します。主にプラグインがこの設定を利用します。

例 (eslint-plugin-react で React のバージョンを指定):

javascript
module.exports = {
// ... extends, plugins など
settings: {
react: {
version: 'detect', // インストールされている React のバージョンを自動検出
// version: '17.0' // 特定のバージョンを指定
},
// eslint-plugin-import でモジュールの解決方法を指定する場合など
'import/resolver': {
node: {
extensions: ['.js', '.jsx', '.ts', '.tsx']
}
}
},
// ...その他の設定
};

どのプラグインがどのような settings をサポートしているかは、各プラグインのドキュメントを確認する必要があります。

3.8. ignorePatterns または .eslintignore: チェック対象から除外するファイル/ディレクトリ

ビルドされたファイル、ライブラリのコード、設定ファイルなど、ESLintのチェックから除外したいファイルやディレクトリを指定できます。これは .eslintignore ファイルを作成するか、.eslintrc.* ファイルの ignorePatterns プロパティを使用します。形式は .gitignore と似ています。

.eslintignore ファイルの例:

“`

ビルドディレクトリを除外

build/
dist/

Node.jsモジュールを除外

node_modules/

ベンダーライブラリを除外

vendor/

特定のファイルを除外

src/legacy/old_script.js
“`

.eslintrc.js で ignorePatterns を使用する例:

javascript
module.exports = {
// ... その他の設定
ignorePatterns: [
'build/',
'dist/',
'node_modules/',
'vendor/',
'src/legacy/old_script.js'
],
};

通常、.eslintignore ファイルを使う方が一般的ですが、全てのESLint関連設定を一箇所にまとめたい場合は ignorePatterns も便利です。両方存在する場合、ESLintは両方を考慮します。

3.9. overrides: 特定のファイルに対する設定の上書き

プロジェクト内で、異なるタイプや環境のファイルが混在している場合、overrides プロパティを使用すると、特定のファイルパターンに対してのみ異なるESLint設定を適用できます。これは、例えばNode.jsのスクリプトとブラウザのフロントエンドコードが混在するプロジェクトや、テストファイルに異なるルールを適用したい場合に非常に便利です。

overrides の値はオブジェクトの配列です。各オブジェクトは以下のプロパティを持ちます。

• files: 設定を適用するファイルパターン（glob形式の文字列または文字列の配列）。必須。
• extends: そのファイルパターンに適用する extends 設定。
• rules: そのファイルパターンに適用する rules 設定。
• env: そのファイルパターンに適用する env 設定。
• globals: そのファイルパターンに適用する globals 設定。
• parserOptions: そのファイルパターンに適用する parserOptions 設定。
• settings: そのファイルパターンに適用する settings 設定。

例:

“`javascript
module.exports = {
// 全体的な設定（プロジェクトの多くのファイルに適用されるデフォルト）
env: {
browser: true,
es2021: true,
},
extends: [
‘eslint:recommended’,
// …その他の全体設定
],
rules: {
‘no-console’: ‘warn’, // 全体的に console.log は警告
// …その他の全体ルール
},

// 特定のファイルに対する設定の上書き
overrides: [
{
// Node.js スクリプト (.js ファイルだが Node.js 環境)
files: [
‘.eslintrc.js’, // この設定ファイル自体も含む
‘webpack.config.js’,
‘scripts//*.js’,
],
env: {
node: true, // Node.js 環境を有効にする
browser: false, // ブラウザ環境を無効にする
},
rules: {
‘no-console’: ‘off’, // Node.js スクリプトでは console.log を許可
},
},
{
// テストファイル (.test.js または .spec.js)
files: [
‘/.test.js’,
‘/.spec.js’,
],
env: {
jest: true, // Jest 環境を有効にする
node: true, // テストは Node.js 上で実行されることが多い
},
// テストファイルでは特定のルールを無効にするなど
rules: {
‘no-unused-expressions’: ‘off’, // chaiなどのアサーションライブラリで必要になる場合がある
},
},
{
// TypeScript ファイル (.ts, .tsx)
files: [
‘/*.ts’,
‘/*.tsx’
],
parser: ‘@typescript-eslint/parser’,
parserOptions: {
project: [‘./tsconfig.json’], // 型情報が必要なルールのため
},
extends: [
‘plugin:@typescript-eslint/recommended’,
// 型情報が必要なより厳格なルールを使いたい場合
// ‘plugin:@typescript-eslint/recommended-requiring-type-checking’,
],
rules: {
// TypeScript固有のルール設定や、JSルールの上書き
‘@typescript-eslint/explicit-function-return-type’: ‘off’, // 例: 戻り値の型推論を許可
},
},
],
};
“`

overrides は非常に強力で、複雑なプロジェクト構成でもESLint設定を整理しやすくします。特定のファイルに適用される設定は、全体設定 -> extends で継承された設定 -> overrides の順で適用・上書きされます。同じファイルに複数の overrides がマッチする場合、配列で後に定義されている overrides が優先されます。

3.10. 設定ファイルの優先順位とカスケード

ESLintは、以下の場所から設定ファイルを読み込みます（優先順位が高い順）。

1. package.json の eslintConfig フィールド
2. .eslintrc.js または .eslintrc.yaml または .eslintrc.yml または .eslintrc.json (いずれか最初に見つかったもの)
3. .eslintrc (非推奨の古い形式)

ESLintは、チェック対象ファイルのディレクトリから始まり、親ディレクトリを辿って設定ファイルを探します。特定のディレクトリに .eslintrc.* ファイルが存在する場合、そのファイルはそのディレクトリとそのサブディレクトリ内のファイルに適用されます。

デフォルトでは、ESLintは親ディレクトリの設定ファイルをマージしてカスケードします。つまり、サブディレクトリの設定は親ディレクトリの設定を継承し、それを上書きできます。この挙動は、設定ファイルに root: true を設定することで停止させることができます。root: true を設定したディレクトリより上の階層にある設定ファイルは無視されます。これは通常、プロジェクトのルートディレクトリにある設定ファイルに設定します。

javascript
// プロジェクトのルートディレクトリの .eslintrc.js
module.exports = {
root: true, // この設定ファイルがプロジェクトのルートであることを示す
// ... 以降の設定はこのディレクトリ以下にのみ影響し、親ディレクトリの設定は無視される
};

4. どう使う？：ワークフローへの組み込み (Integrating into Your Workflow)

ESLintの最大の効果は、開発者が問題を 早期に 知ることができる点にあります。そのためには、ESLintを開発ワークフローの様々な段階に組み込むことが重要です。

4.1. エディタ連携

ESLintをエディタと連携させることは、開発体験を劇的に向上させます。コードを書いている最中にリアルタイムでESLintの警告やエラーがハイライト表示されるため、問題をすぐに発見し修正できます。

多くのモダンなエディタには、ESLint連携のためのプラグインや拡張機能が用意されています。

• VS Code: ESLint Extension (Microsoft公式) が最も一般的です。インストールすれば、.eslintrc.* ファイルが存在するプロジェクトで自動的に動作します。保存時に自動修正する設定 (editor.codeActionsOnSave) もよく使われます。
• Sublime Text: SublimeLinter-eslint
• Atom: linter-eslint
• WebStorm (IntelliJ IDEA): 標準機能として強力なESLintサポートが内蔵されています。設定で有効化し、ESLintパッケージのパスなどを指定します。

エディタ連携を設定するだけで、開発中のコードの品質が向上し、後で大量の警告やエラーに直面するストレスを軽減できます。

4.2. npmスクリプト

前述したように、package.json に lint スクリプトを追加しておくと、プロジェクト全体をチェックしたり、自動修正したりするのに便利です。

json
"scripts": {
"lint": "eslint .",
"lint:fix": "eslint . --fix",
"check-format": "prettier --check .", // 後述のPrettier連携用
"format": "prettier --write ." // 後述のPrettier連携用
}

これらのスクリプトは、開発者がコードをコミットする前や、プルリクエストを作成する前に手動で実行できます。

4.3. Git Hooks (Husky + lint-staged)

手動での npm run lint は忘れがちです。Gitフックを利用すると、特定のGitイベント（コミット前、プッシュ前など）が発生した際に、ESLintを自動的に実行できます。これにより、問題のあるコードがリポジトリにコミットされたり、プッシュされたりするのを防ぐことができます。

pre-commit フックでステージングされているファイルのみを対象にESLintを実行するのが一般的です。これにより、コミットしようとしているコードにのみチェックがかかるため、高速に実行できます。

これには、Husky (Gitフックを簡単に設定できるツール) と lint-staged (Gitのステージングエリアにあるファイルに対してコマンドを実行できるツール) を組み合わせるのがデファルトになっています。

1. インストール:
   bash
npm install --save-dev husky lint-staged eslint prettier # prettierも一緒にインストールする場合
# または
yarn add --dev husky lint-staged eslint prettier
2. Huskyの設定:
   • package.json に prepare スクリプトを追加 (Husky 7+ の場合):
     json
"scripts": {
"prepare": "husky install",
"lint": "eslint .",
"lint:fix": "eslint . --fix",
// ... その他のスクリプト
}
   • インストールコマンドを実行: npm run prepare または yarn prepare
   • pre-commit フックを追加: npx husky add .husky/pre-commit "npx lint-staged"
3. lint-stagedの設定:
   package.json に lint-staged 設定を追加します。対象ファイルと実行するコマンドを指定します。
   json
{
// ... その他の設定
"lint-staged": {
"*.{js,jsx,ts,tsx}": [
"eslint --fix", // ESLintで自動修正を試みる
"prettier --write", // Prettierでフォーマット (後述)
"git add" // 修正・フォーマットされたファイルを再度ステージングに追加
],
"*.{json,css,md}": [
"prettier --write", // JS/TS以外のファイルもPrettierでフォーマット
"git add"
]
}
}

これで、git commit を実行する前に、ステージングされている.js, .jsx, .ts, .tsx ファイルに対してESLintの自動修正 (--fix) が実行され、Prettierによるフォーマットも行われます。もしESLint --fix でも修正できないエラーが残っている場合、コミットは失敗し、その旨が報告されます。開発者はエラーを修正してから再度コミットする必要があります。

この仕組みにより、問題のあるコードがリポジトリに入ることを強力に防ぎ、コードの品質とスタイルの一貫性をチーム全体で維持しやすくなります。

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

Gitフックはローカル開発環境でのチェックに有効ですが、開発者がフックをバイパスしたり、設定ミスがあったりする可能性もゼロではありません。より確実な品質保証のためには、Continuous Integration (CI) 環境でESLintチェックを実行することが不可欠です。

CIパイプラインでは、コードがリポジトリにプッシュされたり、プルリクエストが作成されたりするたびに自動的にテストやリンティングが実行されます。

CI設定ファイル (例: GitHub Actions, GitLab CI, Jenkins, CircleCIなど) で、ビルドやテストのステップの一部としてESLintの実行コマンド (npm run lint や yarn lint) を追加します。

GitHub Actions の例 (.github/workflows/ci.yml):

“`yaml
name: CI

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

jobs:
lint-and-test:
runs-on: ubuntu-latest

steps:
- uses: actions/checkout@v3

- name: Set up Node.js
  uses: actions/setup-node@v3
  with:
    node-version: '18' # プロジェクトで使用しているNode.jsバージョン

- name: Install dependencies
  run: npm ci # npm install の代わりに npm ci を推奨 (より安定)

- name: Run ESLint
  run: npm run lint # package.json で定義した lint スクリプトを実行

# ... その他のテストステップなど

“`

CI環境で npm run lint (つまり eslint .) を実行すると、ESLintは警告やエラーが見つかった場合に非ゼロの終了コードを返します。CIサーバーはこれを受け取ってジョブを失敗させ、開発者に問題があることを通知します。これにより、マージ前にコードの問題を発見できます。

5. ESLintとPrettierの連携 (ESLint + Prettier)

前述のように、ESLint（リンター）とPrettier（フォーマッター）は役割が異なりますが、組み合わせて使うことでコード品質とスタイルの一貫性を高いレベルで実現できます。ただし、ESLintにもスタイルに関するルールがあるため、Prettierと競合する可能性があります。

例えば、ESLintの indent ルールとPrettierのインデント設定が異なっていたり、ESLintの quotes ルールとPrettierの引用符設定が異なっていたりすると、ツールを実行するたびにコードスタイルが揺れてしまいます。

この問題を解決するために、以下のプラグインと設定を使用するのが標準的な方法です。

1. eslint-config-prettier: ESLintのスタイルに関するルールの中で、Prettierと競合する可能性のあるものを 全て無効化 するための設定です。これは extends で使用します。
2. eslint-plugin-prettier: ESLintのルールとしてPrettierを実行するためのプラグインです。これにより、Prettierで検出されたフォーマットの不一致をESLintのエラーとして報告できます。また、eslint --fix でPrettierによる自動フォーマットを実行できるようになります。これは plugins と extends (plugin:prettier/recommended) で使用します。

推奨される設定手順は以下の通りです。

1. 必要なパッケージのインストール:
   bash
npm install --save-dev prettier eslint-config-prettier eslint-plugin-prettier
# または
yarn add --dev prettier eslint-config-prettier eslint-plugin-prettier

2. .eslintrc.js の設定:
   extends 配列の 末尾 に 'plugin:prettier/recommended' を追加します。plugin:prettier/recommended は、eslint-plugin-prettier と eslint-config-prettier の両方を有効にするショートカットです。extends の末尾に配置することが重要です。これにより、他の全てのESLint設定（スタイルガイドを含む）が適用された後に、Prettierと競合するルールが無効化されます。

   “`javascript
   module.exports = {
   // … env, parserOptions, plugins など

   extends: [
   ‘eslint:recommended’,
   // 使用しているスタイルガイドやプラグインの推奨設定
   ‘airbnb-base’,
   ‘plugin:react/recommended’,
   ‘@typescript-eslint/recommended’,
   // …その他の extends

   // 必ず extends の末尾に記述すること！
   'plugin:prettier/recommended',
   

   ],

   rules: {
   // 個別ルールの上書き（extendsで無効化されたスタイルルール以外）
   // Prettier が担当するスタイルルールをここで有効化したり上書きしたりしないこと！
   ‘no-console’: ‘warn’,
   // …その他のコード品質や潜在バグに関するルール
   },

   // … settings, overrides など
   };
   “`

3. Prettier の設定ファイル (任意):
   Prettier自体の設定（インデント数、行長など）は、.prettierrc.js, .prettierrc.json, .prettierrc.yaml あるいは package.json の prettier プロパティなどで定義します。これはESLintの設定とは別に管理されます。

   .prettierrc.js の例:
   javascript
module.exports = {
singleQuote: true, // シングルクォートを使用
semi: true, // セミコロンを付与
trailingComma: 'es5', // ES5互換の末尾カンマ
tabWidth: 2, // インデントはスペース2つ
printWidth: 100, // 1行の最大文字数
};
   これらの設定が、Prettierのフォーマット時に適用されます。

4. 実行方法:

   • ESLint (--fix 付き) を実行すると、まずESLintの自動修正可能なルールが適用され、その後Prettierによるフォーマットが実行されます。
     bash
npm run lint:fix # package.json に設定した場合
# または
npx eslint . --fix
   • Prettier単独でフォーマットすることも可能です。これはスタイル整形に特化しているため、ESLint --fix よりも高速な場合があります。
     bash
npm run format # package.json に設定した場合
# または
npx prettier --write .
--check オプションで、フォーマットが必要なファイルがないかチェックすることもできます（CIなどで便利）。
     bash
npm run check-format # package.json に設定した場合
# または
npx prettier --check .

連携の考え方:

• ESLint は、コードの品質と潜在バグ（Linterの役割）、そして一部のスタイルルール（Formattingとは関係ないものや、Prettierで担当しないもの）を担当します。
• Prettier は、コードの 見た目 に関するスタイル（インデント、スペース、改行、引用符、セミコロンなど）を 全て 担当します。
• eslint-config-prettier が、ESLintのスタイルルールとPrettierのスタイルの衝突を防ぎます。
• eslint-plugin-prettier が、PrettierをESLintのエラーとして報告させたり、eslint --fix でPrettierを実行できるようにします。

この連携により、「このインデントがおかしい」「セミコロンがない」といったスタイルに関する指摘はPrettierと eslint --fix に任せ、ESLintはより高レベルなコード品質や潜在バグのチェックに注力するという理想的な分業体制が構築できます。

6. トラブルシューティング (Troubleshooting Common Issues)

ESLintの設定は多岐にわたるため、時に予期せぬ問題に遭遇することがあります。ここではいくつかの一般的な問題と解決策を紹介します。

6.1. 「Rule ‘[rule-name]’ is not found」エラー

原因: 指定したルールが、ESLintの組み込みルール、有効なプラグイン、または継承した設定に含まれていない。
解決策:
* ルール名のスペルミスがないか確認する。
* そのルールを含むべきESLintプラグイン（例: Reactルールなら eslint-plugin-react）が package.json の devDependencies にインストールされており、.eslintrc.* の plugins 配列に含まれているか確認する。
* そのルールが extends で指定した設定（スタイルガイドなど）に含まれているか確認する。もし含まれているはずなのにエラーが出る場合は、その設定のパッケージが正しくインストールされているか確認する。

6.2. 「Parsing error: Unexpected token」

原因: ESLintのデフォルトパーサー(Espree)が、コード中の非標準的な構文（JSX, TypeScript, 新しいECMAScriptの機能など）を理解できない。
解決策:
* JSXを使用している場合: parserOptions.ecmaFeatures.jsx: true が設定されているか、または Reactプラグインの推奨設定 (plugin:react/recommended) を extends しているか確認する。
* TypeScriptを使用している場合: @typescript-eslint/parser を parser として指定し、@typescript-eslint プラグインを plugins に含めているか確認する。
* 新しいECMAScriptの機能（例: Optional Chaining ?., Nullish Coalescing ??）を使用している場合: parserOptions.ecmaVersion がこれらの構文をサポートするバージョン（例: 'latest', 2020 以上）に設定されているか確認する。通常、'latest' にしておくのが最も簡単です。

6.3. 想定外の警告/エラー、または警告/エラーが表示されない

原因:
* 設定ファイルが正しく読み込まれていない。
* 複数の設定ファイル（親ディレクトリ、overrides）が競合している。
* .eslintignore や ignorePatterns でファイルが除外されている。
* エディタのESLint拡張機能が正しく設定されていない、または古い。
解決策:
* npx eslint --print-config [your-file.js] コマンドを実行して、特定のファイルに対してESLintが実際に使用している最終的な設定を確認する。これにより、どの設定ファイルやルールが適用されているかをデバッグできます。
* .eslintignore ファイルや ignorePatterns プロパティを確認し、対象ファイルが意図せず除外されていないか確認する。
* .eslintrc.* ファイルに root: true が設定されているか確認する。これにより、意図しない親ディレクトリの設定が適用されるのを防げます。
* overrides の files パターンが正しく、意図したファイルに適用されているか確認する。
* エディタの設定で、ESLintが無効になっていないか、正しいESLint実行ファイル（プロジェクトの node_modules/.bin/eslint）を参照しているか確認する。エディタを再起動してみるのも有効です。

6.4. ESLintの実行が遅い

原因:
* プロジェクトの規模が大きい。
* パフォーマンスの悪いESLintルール（特に型情報が必要なTypeScript関連ルールなど）。
* ESLintやプラグインのバージョンが古い。
* 不必要に多くのファイルがチェック対象になっている。
解決策:
* .eslintignore や ignorePatterns を活用し、チェック不要なファイルやディレクトリ（node_modules, ビルドディレクトリ, ベンダーコードなど）を確実に除外する。
* parserOptions.project で指定する tsconfig.json が、ビルドされる全てのファイルを含んでいると、ESLintの型チェックが遅くなることがあります。ESLintのチェック対象のみを含む、より小さな tsconfig.eslint.json ファイルを作成し、それを指定することも検討する。
* パフォーマンスに影響を与える可能性のあるルール（特に @typescript-eslint/eslint-plugin の推奨設定に含まれる一部のルール）について、公式ドキュメントを確認し、必要に応じて無効化するかレベルを調整する。
* ESLint本体や関連プラグインのバージョンを最新にアップデートする。
* CI環境など、全体のリンティングが必要な場合以外は、lint-staged などで変更されたファイルのみをチェックするようにワークフローを最適化する。

6.5. ESLintとPrettierが競合する

原因: ESLintとPrettierのスタイル設定が異なり、互いにコードを書き換えてしまう。
解決策:
* 必ず eslint-config-prettier を使用する。 これがESLintのスタイル関連ルールを無効化し、競合を防ぎます。.eslintrc.* の extends 配列の 末尾 に 'plugin:prettier/recommended' または 'prettier' (eslint-plugin-prettierを使用しない場合) を追加しているか確認する。
* Prettierのフォーマットルールは、.prettierrc.* ファイルで一元管理する。ESLintの rules でスタイルに関するルール（インデント、セミコロン、引用符など）を 設定しない。Prettierに任せる。
* GitフックなどでESLintとPrettierを実行する場合、常に Prettier を ESLint の 後に 実行するか、eslint --fix に任せる（eslint-plugin-prettier を使用している場合）。lint-staged の設定例を参考に、実行順序を確認する。

これらのデバッグのヒントは、ESLintの問題解決に役立つはずです。最も重要なツールは npx eslint --print-config コマンドです。

7. より高度な使い方 (Advanced Topics)

• カスタムルールの作成: 特定のプロジェクトや組織固有のコーディング規約を強制したい場合、独自のESLintルールを作成することができます。これはESLintの内部APIに関する知識が必要となるため、より高度なトピックです。ESLintの公式ドキュメントに詳細なガイドがあります。
• プロセッサー: ESLintのプロセッサー機能を使用すると、HTMLやMarkdownファイル内に埋め込まれたJavaScriptコードを抽出してリンティングするなど、非JavaScriptファイルを処理できます。
• ESLintのパフォーマンス最適化: 大規模なコードベースでは、ESLintの実行時間が問題になることがあります。キャッシュ機能（デフォルトで有効）の利用、適切な .eslintignore の設定、型チェックを必要とするルールの見直しなどが最適化の鍵となります。

8. まとめ：ESLintを開発の味方に

この記事では、ESLintがなぜJavaScript開発において不可欠なのか、そしてどのように設定し、日々のワークフローに組み込むのかを詳細に解説しました。

ESLintは単なる構文チェッカーではありません。コードスタイルの一貫性を保ち、潜在的なバグを早期に発見し、チーム全体のコード品質を向上させるための強力なツールです。エディタ連携、Gitフック、CI/CDパイプラインへの組み込みにより、その効果は最大限に発揮されます。また、Prettierのようなフォーマッターと連携することで、コードの見た目と品質の両方を高いレベルで維持できます。

ESLintの導入は、最初は少し学習コストがかかるかもしれません。設定ファイルは多くのオプションを持ち、どのルールを使うべきか迷うこともあるでしょう。しかし、eslint --init から始めて、人気のスタイルガイド (extends) を利用し、プロジェクトの要件に合わせて少しずつ rules を調整していくのが良いアプローチです。そして、エディタ連携やGitフックを早めに導入することで、そのメリットをすぐに享受できるはずです。

ESLintをあなたの開発プロセスに積極的に取り入れて、よりクリーンで、よりバグの少ない、そしてより協力しやすいコードベースを構築しましょう。それは、あなた自身だけでなく、チーム全体の生産性と幸福度を高めることにつながります。ESLintをあなたの開発の味方にして、素晴らしいJavaScriptコードを生み出してください！