1. 導入：なぜPeer Dependenciesを知る必要があるのか？
フロントエンド開発などでnpmパッケージをインストールした際、突然「npm ERR! ERESOLVE」というエラーに遭遇したことはありませんか？これは、ライブラリ同士のバージョンが衝突しているサインです。特に「Peer Dependencies（ピア依存関係）」は、初心者の方が最初につまずきやすい難所の一つです。これを正しく理解することで、ビルドエラーを未然に防ぎ、チーム開発でのトラブルを大幅に減らすことができます。
2. 基礎知識：Peer Dependenciesとは？
通常の「Dependencies」は「このライブラリを使うために必要なもの」を指しますが、「Peer Dependencies」は「このライブラリは特定のホスト（親）プロジェクトと一緒に動くことを想定しており、ホスト側でバージョンを管理してほしい」という意思表示です。
例えば、Reactのプラグインを作成する場合、プラグイン側でReactをインストールしてしまうと、プロジェクト内にReactが2つ存在することになり、バグやメモリ消費の原因になります。そのため、「React本体はプロジェクト側で用意してね」と指定するのがPeer Dependenciesの役割です。
3. 実装/解決策：バージョン不整合をどう解決するか
エラーが発生した際、無理やり解決しようとして「–force」や「–legacy-peer-deps」オプションを使うのは最終手段にしましょう。まずは以下の手順で解決を試みてください。
1. エラーログを確認する: npmはエラーログで「どのパッケージが、どのバージョンを要求しているか」を明確に示してくれます。
2. セマンティックバージョニング（SemVer）を確認する: 「^18.0.0」ならメジャーバージョンが18系であることを指します。ホスト側のバージョンがこの範囲内か確認しましょう。
3. パッケージの更新: プロジェクトのpackage.jsonを修正して、要求されているバージョンに合わせます。
4. サンプルプログラム：package.jsonでの定義例
以下は、Reactプラグインを作成する際のpackage.jsonの記述例です。
{
“name”: “my-awesome-plugin”,
“version”: “1.0.0”,
“peerDependencies”: {
// 自分のプラグインはReact 17または18で動作することを明示
“react”: “^17.0.0 || ^18.0.0”
},
“devDependencies”: {
// 開発時のテスト用にReact本体をインストールしておく
“react”: “^18.2.0”
}
}
5. 応用・注意点：現場で陥りやすい罠
現場で最も多いトラブルは、「依存関係を強制的にインストールしすぎて環境が壊れる」ことです。
・–legacy-peer-deps の扱い: npm v7以降、Peer Dependenciesの解決が厳格になりました。エラーが出るたびにこのフラグで回避していると、プロジェクトの依存関係が整合性の取れない状態（依存関係地獄）になります。
・パッケージロックファイルの管理: package-lock.jsonを無視してインストールを繰り返すと、メンバー間で環境が乖離します。必ずロックファイルをコミットし、チーム内でバージョンを統一しましょう。
Peer Dependenciesは、ライブラリ同士が「お互いに正しく動くための約束事」です。エラーが出たら「誰がどのバージョンを求めているのか」を一つずつ紐解くことが、トラブル解決への最短ルートとなります。
コメント