ESLint × Prettier：VSCodeで「なぜか動かない」を永久追放する、究極のコード品質アーキテクチャ
こんにちは。テックリードです。
「保存時にフォーマットされない」「ESLintのルールがPrettierと衝突して地獄になる」……。この手のトラブルを解決するのに、あなたの貴重な開発時間を費やすのは今日で終わりにしましょう。
本記事では、単なる設定の羅列ではなく、VSCodeの内部実行プロセスをハックし、プロジェクト全体で「無意識に美しいコード」が生成されるためのアーキテクチャを伝授します。
—
1. 脳内整理：なぜ「効かない」ことが起こるのか？
原因は常に「設定の競合」か「優先順位の誤解」です。VSCodeは以下の順で設定を読み込みます。
1. Workspace Settings (`.vscode/settings.json`)：最優先。プロジェクト単位で強制すべき設定。
2. User Settings：個人の好み。ここに依存するとチーム開発で必ず崩壊する。
3. Prettier/ESLint Config：言語仕様レベルのルール定義。
「効かない」ときは、User SettingsのゴミがWorkspaceの設定を上書きしているか、拡張機能の実行順序が逆転しているケースが99%です。
—
2. 現場の「神設定」：`.vscode/settings.json` のベストプラクティス
プロジェクトルートの `.vscode/settings.json` にこれを記述してください。これがチームの「共通言語」になります。
{
// デフォルトのフォーマッターをPrettierに強制固定
“editor.defaultFormatter”: “esbenp.prettier-vscode”,
// 保存時にフォーマットを実行（エディタの基本）
“editor.formatOnSave”: true,
// TypeScript/JSのみを対象に、ESLintをフォーマッターとして噛ませる
“[typescript][javascript][typescriptreact][javascriptreact]”: {
“editor.defaultFormatter”: “dbaeumer.vscode-eslint”,
“editor.codeActionsOnSave”: {
“source.fixAll.eslint”: “explicit” // ESLintの自動修正を保存時に走らせる
}
},
// 静的解析の実行トリガーを保存時に限定し、タイピング中のラグを排除
“eslint.run”: “onSave”,
// エディタのタブサイズをPrettierのルールと物理的に同期させる
“editor.tabSize”: 2,
“editor.insertSpaces”: true
}
解説：
ここでの肝は、`editor.defaultFormatter` をあえて二重定義している点です。全体にはPrettierを適用しつつ、TS/JS系だけはESLint（＋Prettierプラグイン）に解決させることで、「Prettierがコードを整形し、その直後にESLintが不要なコードやインポート順を整理する」という完璧なパイプラインが完成します。
—
3. 「神プラグイン」と「隠しコマンド」
生産性を極限まで高めるための、現場で必須の拡張機能とテクニックです。
必須拡張機能
- [ESLint](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint): 言うまでもない必須。
- [Prettier – Code formatter](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode): 必須。
- [Error Lens](https://marketplace.visualstudio.com/items?itemName=usernamehw.errorlens): これ無しで開発するのは目隠しで高速道路を走るようなもの。 コード行の末尾にエラー内容を直接表示させ、修正コストをゼロにします。
伝説のショートカット
- `Shift + Alt + F`：手動フォーマット。保存設定が効かない時の強制トリガー。
- `Ctrl(Cmd) + .` (クイックフィックス)：ESLintが指摘する「修正可能な警告」を一撃で直すための魔法のキー。これを使わないエンジニアは、マウスでメニューを辿る時間が年間数十時間を浪費しています。
—
4. チーム開発における「絶対ルール」：設定の共有化
設定ファイルをGit管理下に置くのは基本ですが、さらに踏み込んで「PrettierとESLintの競合を物理的に消滅させる」構成を推奨します。
以下のパッケージを必ず導入し、プラグインを設定する
npm install –save-dev eslint-config-prettier eslint-plugin-prettier
`.eslintrc.json` に以下の設定を追加してください。
{
“extends”: [
“eslint:recommended”,
“plugin:@typescript-eslint/recommended”,
“plugin:prettier/recommended” // これが最強。PrettierのルールをESLintの警告として統合する
],
“rules”: {
“prettier/prettier”: “error” // Prettier違反をESLintのエラーとして報告させる
}
}
なぜこれが必要か？
`plugin:prettier/recommended` を入れると、Prettierのルール違反が「ESLintの赤波線」として表示されます。つまり、Prettierの設定とESLintのルールが競合する余地そのものを排除するのです。
—
5. テックリードからの提言：CI/CDとの連動
ローカルで直すのは当たり前。「フォーマットされていないコードはコミットさせない、プッシュさせない」のが最強の品質管理です。
`husky` と `lint-staged` を使いましょう。
// package.jsonに追加
“lint-staged”: {
“.{js,ts,tsx}”: [
“eslint –fix”,
“prettier –write”
]
}
この設定により、`git commit` した瞬間に、ステージングされたファイルだけが自動整形されます。チームメンバーの誰がどんなエディタを使っていようと、リポジトリに入るコードは常に完璧なフォーマットが保証されます。
—
まとめ：あなたの開発環境は「自動運転」されているか？
プロフェッショナルの開発とは、コードを書くことそのものよりも、「思考を邪魔するノイズをいかに排除するか」に集約されます。
1. `.vscode/settings.json` でエディタの挙動をプロジェクト単位で強制する。
2. `plugin:prettier/recommended` でルール競合を論理的に殺す。
3. `lint-staged` でゲートキーパーを設置する。
このアーキテクチャを導入すれば、あなたは「コードの見た目」で悩むことから解放され、本来の目的である「ビジネスロジックの構築」に全リソースを集中できるはずです。さあ、今すぐ設定ファイルを見直し、開発の自動運転を始めましょう。