モノレポにおける「ESLint Flat Config」の真髄：スケーラブルな静的解析アーキテクチャの構築
大規模なモノレポ（NxやTurborepo）を運用する際、最も多くのエンジニアが陥る罠は「設定ファイルの肥大化と断絶」です。各パッケージに`.eslintrc.js`が散乱し、ルールの一貫性が失われ、最終的には「eslint-disable」が蔓延する……。これは技術的負債の典型的なパターンです。
今回は、ESLint 9以降で標準となったFlat Config (`eslint.config.js`) を駆使し、モノレポ全体で「型」を共有しつつ、各パッケージが自律的に進化できるスケーラブルな設計思想を伝授します。
—
1. なぜ「Flat Config」がモノレポの救世主なのか
従来のESLint設定は、親ディレクトリから設定を継承する際、マージの挙動が不透明でデバッグが困難でした。Flat Configは単なるJavaScriptの配列として設定を定義します。
最大のメリットは「設定の合成（Composition）」です。
各パッケージの設定ファイルは単なる「設定の断片」であり、動的にマージ可能です。これにより、「コアルールは共通化し、ディレクトリ単位で最適化する」というアーキテクチャが極めて簡潔に実装できます。
—
2. 実践：モノレポ向け設定共有アーキテクチャ
`packages/eslint-config/base.js` のような共有パッケージを作成し、それを各プロジェクトでインポートする戦略をとります。
共有設定の定義 (`packages/eslint-config/base.js`)
import js from “@eslint/js”;
import tsPlugin from “@typescript-eslint/eslint-plugin”;
import tsParser from “@typescript-eslint/parser”;
export const baseConfig = [
js.configs.recommended, // JavaScriptの標準ルール
{
languageOptions: {
parser: tsParser, // TypeScriptパーサーの指定
parserOptions: { project: true },
},
plugins: { “@typescript-eslint”: tsPlugin },
rules: {
“no-console”: “warn”, // 開発効率を考え、エラーではなく警告に
“@typescript-eslint/no-explicit-any”: “error”, // 型の安全性を担保
},
},
];
各プロジェクトでの活用 (`apps/web/eslint.config.js`)
ここで重要なのは、共有設定をインポートし、配列を拡張するだけという点です。
import { baseConfig } from “../../packages/eslint-config/base.js”;
export default [
…baseConfig, // 共有ルールを継承
{
files: [“src//.ts”],
rules: {
// このパッケージ独自のルール（例: React環境特有の制限など）
“react-hooks/exhaustive-deps”: “error”,
},
},
];
—
3. 開発スピードを加速させる「神プラグイン」と設定術
ツールを導入するだけでは不十分です。生産性を極限まで高めるための「隠れた必須設定」を共有します。
絶対に入れるべきプラグイン：`eslint-plugin-perfectionist`
import文やオブジェクトのキー、型定義を自動でアルファベット順に整列させます。
- 理由: GitのDiffを最小化し、コンフリクトを未然に防ぐため。脳のメモリを「整理」に使う必要がなくなります。
開発効率を最大化するTips
1. `lint-staged` × `husky` の厳格化:
コミット時に全ファイルをLintするのではなく、`lint-staged`を用いて変更されたファイルのみを対象にします。
2. VS Code 拡張機能の「Format on Save」とLintの分離:
`editor.codeActionsOnSave` に `source.fixAll.eslint` を設定することで、保存の瞬間にコードが矯正される環境を構築してください。
// .vscode/settings.json
{
“editor.codeActionsOnSave”: {
“source.fixAll.eslint”: “explicit” // ESLintのfixを強制実行
},
“eslint.validate”: [“javascript”, “typescript”, “typescriptreact”]
}
—
4. 現場で震えるほど役立つ「チーム運用の鉄則」
ツールを導入した後の「運用」こそがテックリードの腕の見せ所です。
- ルール導入の「段階的昇格」:
新しいルールを導入する際、いきなり `error` にするとCIが全落ちしてチームが疲弊します。最初は `warn` で運用し、Dashboard等のメトリクスで減少傾向を確認してから `error` に切り替える「段階的ロールアウト」を行ってください。
- 設定の「単一責任の原則」:
`eslint.config.js` が500行を超えたら、即座に機能ごとにファイルを分割してください。`eslint.config.imports.js`, `eslint.config.react.js` のように分離し、インポートで管理します。
- 「なぜこのルールがあるのか」をコメントせよ:
`.eslintrc` 内の複雑なルールには必ずコメントを残してください。
// 理由: 特定のレガシーAPIとの衝突を避けるため（@team-name 2023-10-01）
“no-restricted-imports”: [“error”, “path/to/legacy”],
—
最後に：静的解析は「守り」ではなく「攻め」の道具
優秀なエンジニアは、Lintを「コードを縛る足枷」とは考えません。「コードの品質を担保し、レビュアーがビジネスロジックの改善に集中するためのインフラ」だと認識しています。
ESLint Flat Configという柔軟な武器を手に入れた今、あなたのモノレポはより強固で、かつ変更に強い構造へと進化できるはずです。まずは共有設定のパッケージ化から始めてみてください。その一歩が、数ヶ月後のチームの爆速開発を支える強固な土台となります。
さあ、コードを美しく、そして何より「速く」書きましょう。