ESLint「Parsing error」の深淵を暴く：パーサーのメカニズムを掌握し、開発速度を極限まで高める
開発現場で突如として現れる「Parsing error」。赤い波線がコード全体を覆い、脳内の生産性フローが断ち切られるあの瞬間ほど、エンジニアにとって忌々しいものはありません。
単なる「設定ミス」と片付けていては、また明日同じエラーに遭遇します。このエラーは、「ESLintがあなたのコードの抽象構文木（AST）を構築する過程で、期待した仕様と食い違っている」という警告です。
今日は、小手先の修正ではなく、ESLintの解析エンジンそのものを制御下に置き、開発体験を劇的に改善するための「アーキテクト級の処方箋」を伝授します。
—
1. Parsing errorの真因を解剖する
Parsing errorが発生する時、ESLintは「コードを理解できない」と悲鳴を上げています。主な原因は以下の3点に集約されます。
1. Parser/Pluginの不一致: TypeScriptの新しい構文（DecoratorsやSatisfies演算子など）を使っているのに、`@typescript-eslint/parser`のバージョンが追いついていない。
2. TSConfigとの乖離: ESLintが参照すべき`tsconfig.json`が正しく解決されておらず、型定義のないJSとして解析しようとしている。
3. 環境設定の欠如: グローバル変数（`browser: true`や`node: true`）が明示されず、標準外のAPIを構文エラーと誤認している。
解決の鍵：`parserOptions.project` の最適化
多くのプロジェクトで「遅い」と感じる原因は、ESLintがすべてのファイルを再解析していることにあります。以下の構成を推奨します。
// .eslintrc.json のベストプラクティス構成
{
“parser”: “@typescript-eslint/parser”,
“parserOptions”: {
// プロジェクトルートからの相対パスで明示的に指定することで、AST解析の精度を上げる
“project”: [“./tsconfig.json”],
“ecmaVersion”: 2022,
“sourceType”: “module”
},
“plugins”: [“@typescript-eslint”],
“rules”: {
// 構文解析の精度を担保するため、型情報が必要なルールを有効化する
“@typescript-eslint/await-thenable”: “error”
}
}
—
2. 開発スピードを加速させる「神プラグイン」と設定術
エンジニアの時間は有限です。手動でLintを実行しているようでは、一流とは言えません。
導入すべき絶対的プラグイン
- `eslint-plugin-import`: 巨大なコードベースで「存在しないモジュール」を即座に検知。
- `eslint-plugin-unused-imports`: 不要なimport文をセーブ時に自動削除。これだけでコードの視認性が数％向上します。
チーム開発の生産性を底上げする「共有設定」
チームで「Lintが通らない」「フォーマットが違う」という不毛な議論を避けるには、`extends`による設定の継承を厳格化してください。
// チーム共通の .eslintrc.js
module.exports = {
extends: [
“eslint:recommended”,
“plugin:@typescript-eslint/recommended”,
“plugin:prettier/recommended” // Prettierとの競合を完全に排除する
],
// ルールを直接書かず、設定を「外部化」してnpmパッケージで管理すると尚良し
rules: {
“no-console”: “warn”, // 運用ルールとして強制
}
};
—
3. 生産性を最大化するVS Codeの「魔改造」設定
IDEの力を借りなければ、現代の開発は立ち行かない。`.vscode/settings.json` を以下のように設定してください。これにより、「保存するたびに、静的解析とフォーマットが完了する」環境が手に入ります。
{
“editor.formatOnSave”: true, // 保存時にPrettier発動
“editor.codeActionsOnSave”: {
“source.fixAll.eslint”: “explicit” // 保存時にESLintの修正ルールを適用
},
“eslint.validate”: [
“javascript”,
“javascriptreact”,
“typescript”,
“typescriptreact”
]
}
プロのショートカット:
- `Cmd + .` (Ctrl + .): ESLintのエラー箇所で即座にQuick Fixを表示。
- `Cmd + Shift + P` -> `ESLint: Restart ESLint Server`: エラーが消えない時の「最終兵器」。サーバーを再起動するだけで解決するケースは多々あります。
—
4. チームへの導入・運用ルール（アーキテクトの知見）
最後に、ツールを導入しても組織に浸透しなければ意味がありません。
1. Huskyによる強制: `pre-commit`フックで `lint-staged` を使い、コミット前にエラーがある場合はコミットを拒否してください。「壊れたコードをリポジトリに入れない」のが鉄則です。
2. ESLintの警告を「無視」しない: `// eslint-disable-next-line` を多用するエンジニアがいたら要注意。なぜそのエラーが出るのかを理解させ、プロジェクト全体の型定義や設定を見直すことが、結果的に技術負債を返済する最速の道です。
3. CI/CDへの組み込み: ローカルだけでなく、GitHub Actions等で `eslint –max-warnings 0` を実行し、CI上でエラーを弾くフローを構築してください。
まとめ
Parsing errorを解決することは、単なるエラー解消ではありません。「コードの構造をプログラムに正しく理解させる」という、高品質なソフトウェア開発の基礎体力作りです。
今日から設定ファイルを見直し、IDEをチューニングし、機械に任せられることは全て機械に任せてください。空いたその時間こそが、エンジニアであるあなたが「本質的な機能実装」に没頭するための貴重な資産となります。
さあ、コードベースをクリーンに保ち、圧倒的なスピードで価値を提供しましょう。