ESLintプラグイン開発：属人化を「型」に変え、開発速度を極限まで引き上げるアーキテクチャ設計
多くのチームが「ESLintの設定ファイルが肥大化し、誰も全容を把握できない」という地獄に陥っています。しかし、真のテックリードは、共通ルールを`.eslintrc`に書き連ねるのではなく、「社内専用のESLintプラグイン」としてパッケージ化し、それを配布・管理します。
なぜか？ ルールをコードとしてカプセル化することで、バージョン管理が可能になり、プロジェクトを跨いだ「開発の型」を強制的に共有できるからです。本稿では、単なるツールの使い方ではなく、組織の生産性を根底から変える「静的解析のアーキテクチャ」を伝授します。
—
1. なぜ「設定ファイルのコピペ」は死を招くのか
プロジェクトごとに設定をコピペしているチームは、ルールが形骸化し、技術負債が雪だるま式に増えていきます。
- バージョン管理の欠如: ルールを変更した際、全プロジェクトの`.eslintrc`を修正するのは現実的ではありません。
- 文脈の欠如: 「なぜこのルールが必要なのか」という背景が消え、単なる「禁止事項」として扱われます。
自作プラグインとしてパッケージ化すれば、`npm install`一つで全ルールが適応され、重大なバグやスタイルの不一致をCI上で確実にブロックできます。
—
2. ESLintプラグイン開発の神髄：Yeomanによる高速立ち上げ
ゼロからファイル構成を考えるのは時間の無駄です。公式が提供するスキャフォールディングツールを使い、本質的な「ルールロジック」に集中します。
1. ジェネレーターのインストール
npm install -g yo generator-eslint
2. プラグインの雛形生成
mkdir eslint-plugin-company-rules && cd $_
yo eslint:plugin
3. ルール(Rule)の追加
yo eslint:rule
ここで重要なのは、「ルールの命名規則」です。`eslint-plugin-company-rules/no-direct-state-mutation` のように、何をするルールなのかを一目で理解できるようにしてください。
—
3. テストこそが最強のドキュメント：RuleTesterの実践
ESLintプラグイン開発において、`RuleTester`は単なるテストツールではありません。「コードの仕様書」そのものです。
// lib/rules/no-direct-state-mutation.js
const RuleTester = require(“eslint”).RuleTester;
const rule = require(“./no-direct-state-mutation”);
const ruleTester = new RuleTester({ parserOptions: { ecmaVersion: 2020 } });
ruleTester.run(“no-direct-state-mutation”, rule, {
valid: [{ code: “this.setState({ count: 1 });” }], // 合格パターン
invalid: [
{
code: “this.state.count = 1;”, // 違反パターン
errors: [{ message: “直接stateを更新してはいけません。” }],
},
],
});
このテストコードがCIで回ることで、「どの書き方が許容され、どれが禁忌なのか」がチームの誰の目にも明らかになります。これが最強のナレッジ共有です。
—
4. 開発を加速させる「ローカルリンク」の魔法
公開前に検証する際、`npm publish`を繰り返してはいけません。`npm link`を活用し、開発中のプロジェクトへ即座に反映させるのが鉄則です。
プラグイン側のディレクトリで実行
npm link
適用したいプロジェクト側で実行
npm link eslint-plugin-company-rules
この構成により、プラグインを修正した瞬間に、メインプロジェクトのIDE（VS Code等）でエラーが即時検知されるようになります。このフィードバックループの短縮こそが、開発効率を爆発的に高める鍵です。
—
5. チーム開発を劇的に変える「神設定」のベストプラクティス
プラグイン化と同時に、`.eslintrc.js`も「継承」を前提とした設計に切り替えます。
// .eslintrc.js の理想的な構成
module.exports = {
extends: [
“eslint:recommended”,
“plugin:company-rules/recommended” // 自作プラグインを継承
],
rules: {
// プロジェクト固有の微調整のみをここに記載する
“no-console”: “warn”
}
};
チーム開発の生産性を底上げするツールセット
1. ESLint / Prettier 拡張: VS Codeの `editor.codeActionsOnSave` を活用し、保存時に自動整形・Lintを実行する設定はもはや義務です。
2. Lint-staged: コミット直前に差分のみをチェックさせることで、CIの待ち時間を最小化します。
- `”lint-staged”: { “.{js,ts}”: “eslint –fix” }`
3. eslint-plugin-import: 依存関係の整理を自動化。循環参照を未然に防ぐだけで、アーキテクチャの崩壊を数年単位で防げます。
—
アーキテクトからの提言：コードは「会話」である
ESLintルールを自作するということは、チームに対して「我々はどうコードを書くべきか」という宣言を行うことです。
単にエラーを出すだけの冷たいツールではなく、テストコードにコメントを残し、READMEには「なぜこのルールが必要なのか（例：State直接操作によるバグが過去に3回発生したため）」という背景を記述してください。
この「ルールという名のナレッジ共有」こそが、優秀なテックリードが率いるチームと、そうでないチームを分かつ決定的な差となります。今すぐ、あなたのチームの「暗黙の了解」をコードに落とし込み、持続可能な開発環境を構築してください。