こんにちは。開発環境の設計を専門にしているエンジニアです。
多くのエンジニアが「なぜか動かない」「設定を変えてもエラーが消えない」と頭を抱えるESLintの「Parsing error」。このエラーが出たとき、多くの人はエラーメッセージをそのままGoogle検索して、誰かが書いた適当な `.eslintrc` をコピペして凌いでしまいます。しかし、それでは「なぜ動いたのか」が分からず、数日後にまた同じ地獄を見ることになります。
今回は、ESLintがコードをどう読み取り、なぜ「Parsing error（構文解析エラー）」を吐くのか、その本質的な仕組みを解き明かします。これを理解すれば、もう二度と設定地獄に陥ることはありません。
—
1. なぜ「Parsing error」は発生するのか？
ESLintは、単なるテキストチェッカーではありません。あなたのコードを「抽象構文木（AST：Abstract Syntax Tree）」というツリー構造に変換し、その構造がルールに適合しているかを判断する「コンパイラの一種」です。
「Parsing error」とは、ESLintがコードを解析しようとした瞬間に、「この構文、今の僕の辞書（パーサー）には載っていないよ！」と匙を投げた状態を指します。
主な原因はシンプルです。
1. パーサーの食い違い: JSとして読ませようとしているのに、中身はTSやReactのJSXである。
2. 言語仕様の乖離: 最新のECMAScript機能（ES2024など）を使っているのに、ESLintの設定が古い。
3. プロジェクトの階層構造: `tsconfig.json` が読み込まれておらず、TSの型推論が効かない場所で解析しようとしている。
—
2. 鋼鉄の基礎セットアップ：`@typescript-eslint` の真実
モダンな開発において、ESLintにTypeScriptを正しく教え込むには、標準のパーサーではなく `@typescript-eslint/parser` を使うのが絶対的な鉄則です。
最強の `.eslintrc.js` 構成案
以下の設定は、あらゆるParsing errorを根絶するための「基準点」です。
module.exports = {
// ESLintにTypeScript専用のパーサーを教える
parser: ‘@typescript-eslint/parser’,
parserOptions: {
// どのTS設定を基準に解析するか（プロジェクトのルートを指定）
project: ‘./tsconfig.json’,
// JSXを解析可能にする
ecmaFeatures: { jsx: true },
// 最新のECMAScript仕様を許可する
ecmaVersion: 2022,
sourceType: ‘module’,
},
plugins: [‘@typescript-eslint’],
extends: [
‘eslint:recommended’,
‘plugin:@typescript-eslint/recommended’,
],
rules: {
// 必要に応じて厳格さを調整
}
};
ここが重要: `parserOptions.project` を指定すると、ESLintは裏でTypeScriptコンパイラを起動し、型情報を参照しながら解析を行います。これが「Parsing error」を防ぐ最大の防壁になります。
—
3. 「Parsing error」を叩き潰す3つのチェックリスト
もしエラーが消えないなら、この順番で確認してください。
① `tsconfig.json` の include 範囲
ESLintが解析対象としているファイルが、`tsconfig.json` の `include` に含まれていないと、パーサーは「このファイルは関係ない」と判断して解析を放棄します。
- 確認: `.eslintrc.js` がプロジェクトのルートにあるか、`tsconfig.json` がそのファイルをカバーしているか確認してください。
② パーサーの競合（プラグインの罠）
`eslint-plugin-react` や `eslint-plugin-vue` を併用している場合、パーサーが競合することがあります。
- 解決: 基本的に `parser` は `@typescript-eslint/parser` に固定し、各プラグインは `plugins` セクションで読み込むだけに留めてください。
③ キャッシュの汚染
ESLintは高速化のためにキャッシュを作成します。設定を変えてもエラーが変わらない場合、キャッシュが悪さをしている可能性が高いです。
- 解決: ターミナルで以下を実行し、キャッシュを強制削除してください。
npx eslint –fix . –cache –debug
もしくは物理削除
rm -rf .eslintcache
—
4. 動作確認：あなたの環境は健全か？
正しく設定できたかを確認するには、あえて「解析に失敗しそうなコード」を書いてみるのが一番です。
`test.ts` を作成:
// 型注釈はTS専用の構文。これがパースできれば設定は完璧
const greet: string = “Hello, Architecture!”;
// オプショナルチェイニング（比較的新しい構文）
const user = { name: “Dev” };
console.log(user?.name);
実行コマンド:
npx eslint test.ts –no-ignore
もしここで `Parsing error` が出るなら、パーサーの設定が読み込まれていません。何も出なければ、それは「あなたのコードが完璧に解析され、ルールに違反していない」という最高の結果です。
—
最後に：なぜ手間をかけてまで設定するのか
設定ファイルと格闘するのは面倒ですよね。しかし、この設定を行うことは、あなたのコードの「健康診断の精度」を上げることと同義です。
一度この堅牢なアーキテクチャを構築してしまえば、あなたは「構文エラー」という無駄なデバッグから解放され、本来注力すべき「ビジネスロジック」や「ユーザー体験」の向上に集中できるようになります。
この知見が、あなたの開発ライフをより知的で、より快適なものにすることを願っています。何か詰まったら、いつでも戻ってきてくださいね。