モノレポの混沌を制する：ESLint Flat Configで実現する「継承戦略」の極意
こんにちは。大規模なフロントエンド開発の現場で「設定ファイルの迷宮」に迷い込んだことはありませんか？
NxやTurborepoを使ったモノレポ環境で、パッケージが増えるたびに `eslintrc.json` をコピー＆ペーストし、結局どれが最新ルールかわからなくなる……そんな負の連鎖を断ち切る時が来ました。
今回は、ESLintの次世代アーキテクチャである 「Flat Config」 を活用し、モノレポ全体を俯瞰しながら各パッケージの個性を尊重する、極めてスケーラブルな設定戦略を伝授します。これをマスターすれば、あなたのチームのコード品質管理は、メンテナンスフリーに近い領域へと進化します。
—
1. なぜ「Flat Config」なのか？：設計思想の転換点
従来のESLint設定（`.eslintrc.js`など）は、ディレクトリごとに設定を再帰的にマージする仕様でした。これは直感的なようでいて、実は「どこでルールが上書きされているか追跡不能」になるという、アーキテクチャ上の爆弾を抱えていたのです。
一方、Flat Config（`eslint.config.js`）は、「配列による単純な積み重ね」という設計思想を採用しています。
- カスケードの廃止: 設定の衝突をファイル階層に依存させず、配列の順序だけで決定する。
- モジュールベース: 設定自体がただのJavaScriptオブジェクトの配列であるため、関数で動的に生成したり、ロジックを組み込むことが容易。
モノレポにおいて「共有設定をベースに、特定のパッケージだけルールを足す」という作業が、これほど美しく書けるようになったことは革命的です。
—
2. 基盤構築：共有設定を「関数」として定義する
モノレポのルート直下に設定を集中させるのではなく、`packages/eslint-config` のような共有パッケージを作成し、そこから設定を「提供」する形をとります。
以下のコードは、共有設定を動的に生成するためのテンプレートです。
// packages/eslint-config/base.js
import js from “@eslint/js”;
import tseslint from “typescript-eslint”;
// 各プロジェクトの設定をラップして拡張可能にする関数
export const createConfig = (overrides = []) => [
js.configs.recommended, // JSの推奨設定
…tseslint.configs.recommended, // TSの推奨設定
{
rules: {
// 全プロジェクト共通の厳格なルール
“@typescript-eslint/no-unused-vars”: “error”,
“no-console”: “warn”,
},
},
…overrides, // 各アプリ固有のルールをここで注入
];
このように「関数」としてエクスポートすることで、各アプリケーションは「このベース設定に、これだけ追加したい」という宣言的な記述が可能になります。
—
3. プロジェクト別設定：継承戦略の実践
各パッケージ（例: `apps/web-app`）では、ルートの共有設定をインポートし、必要なルールだけをオーバーライドします。
// apps/web-app/eslint.config.js
import { createConfig } from “@repo/eslint-config”;
export default createConfig([
{
// Webアプリ特有の設定
files: [“src//.tsx”],
rules: {
“react/react-in-jsx-scope”: “off”, // Next.js環境なので不要
},
},
]);
このアプローチの何が凄いのか。それは「設定の依存関係が明示的である」という点です。どのファイルがどの設定を継承しているかがコードとして追えるため、デバッグ時に「なぜこのエラーが出ているのか？」と悩む時間が劇的に減ります。
—
4. 現場で震えるほど役立つ「動作確認」の鉄則
「HelloWorld」的に導入する際は、いきなり全ファイルを解析させず、特定のコマンドで設定の適用状況を確認してください。
設定が正しくマージされているかを確認するコマンド
npx eslint –print-config apps/web-app/src/index.tsx
このコマンドを実行すると、最終的に適用される全てのルールとプラグインのリストがJSON形式で出力されます。
もしルールが効いていないと感じたら、このコマンドで「自分の記述したルールが、配列のどの位置で評価されているか」を確認してください。Flat Configにおいて、配列の後ろにあるものが優先されるという原則さえ守れば、もう迷うことはありません。
—
まとめ：毎日のコーディングを劇的に楽にするために
今回紹介したFlat Configによる継承戦略は、単なるコード規約の統一ではありません。「開発者がルールに縛られるのではなく、ルールが開発者の体験を支える環境」を作ることこそが、アーキテクトの真の仕事です。
1. 設定をロジックとして扱う（関数化）
2. 依存関係を明示的にする（インポート）
3. print-configで答え合わせをする
これらを守るだけで、モノレポ特有の「設定のゴミ溜め」化は防げます。あなたのチームが、設定ファイルと格闘する時間を減らし、本来の価値あるロジック開発に没頭できることを願っています。
さあ、今日から設定ファイルを「整理整頓」ではなく「設計」してみませんか？