もう迷わないnpm：インストール方法と -g／–save-dev の意味を丸ごと理解

npmとインストール範囲の考え方

npmはJavaScriptのパッケージを管理する道具です。必要なツールやライブラリを、コマンドで入れたり更新したりできます。ここで重要なのは「どこにインストールされるか」です。範囲は大きく、PC全体で使うグローバルと、プロジェクト内だけで使うローカルの2つがあります。

グローバルは、複数のプロジェクトで共通のCLI（コマンド）を使うときに便利です。たとえば、よく使う開発支援ツールなどです。ローカルは、そのプロジェクトでだけ必要なライブラリを管理します。再現性を保ち、チームで同じ動作を得やすくなります。

どちらが正しいかは、目的で決まります。CLIをどこでも実行したいならグローバル。アプリの実行やビルドに必要ならローカル。まずはこの考え方を押さえてから、各オプションを見ていきます。

よくある質問：Node.jsを入れたらnpmはもう準備OK？

多くの環境では、Node.jsをインストールするとnpmも一緒に入ります。バージョンは時期によって違うため、必要に応じて更新コマンドで上げることもあります。会社やチームの方針がある場合は、それに合わせると混乱が減ります。

-gオプション：グローバル（Global）インストール

-gは、パッケージをPC全体で使える場所に入れます。インストールしたCLIを、どのフォルダからでも呼び出せます。複数のプロジェクトで同じツールを使うなら、作業が軽くなります。ただし、プロジェクトごとのバージョン分けは難しくなります。

役割と特徴

• 複数プロジェクトで共通のCLIを使いたいときに向いています。
• PATHに登録され、どの場所からでもコマンドを実行できます。
• バージョンの切り替えは手作業になりやすく、更新管理が分散しがちです。
• チームで同じ環境を前提にするときは、版ずれが起きないように合意が必要です。

グローバルインストールの例

• よく使うスキャフォールド系ツールの実行コマンド
• フォーマッタや静的解析ツールのランチャー
• ローカルに置くと重くなる大きめのCLIランタイム

よくある質問：-gで入れるとプロジェクトごとにバージョンは分けられない？

グローバルは基本的に一つのバージョンになります。プロジェクトごとに違う版が必要なら、ローカルに入れてプロジェクトに合わせる方法が分かりやすいです。どうしても分けたいときは、実行時にプロジェクトのローカル版を優先させる運用を検討します。

オプションなし：ローカル（Local）インストール

オプションなしのインストールは、現在のプロジェクト内にパッケージを入れます。プロジェクトの依存として記録されるため、別の開発者や別のPCでも同じ環境を再現しやすくなります。ビルドや実行に必要なライブラリは、基本的にローカルで管理します。

役割と特徴

• プロジェクトの再現性を高め、チームで同じ結果を得やすくします。
• 依存関係は設定ファイルに記録され、インストールコマンドで復元できます。
• CLIであっても、プロジェクト内の実行方法を用意すれば使えます。
• ディスク使用量は増えますが、バージョンを安全に固定しやすいです。

ローカルインストールの例

• そのアプリの動作に必要なフレームワークやライブラリ
• ビルドやテストで使うツール一式
• プロジェクト固有のプラグインや拡張

よくある質問：ローカルに入れたCLIはnpxで実行できる？

多くのCLIは、プロジェクト直下でnpxやスクリプト経由で動かせます。グローバルに入れなくても、プロジェクトごとに必要な版で実行できます。実行方法はプロジェクトのガイドに書いておくと、チーム全体で迷いません。

その他の主要なオプション

ここでは、よく目にする追加オプションをまとめます。目的は主に、依存の種類を分けること、インストールの扱いを調整すること、バージョンの固定度を上げることにあります。使いどころを短く覚えておくと、日々の作業が安定します。

A. –save-dev または -D：開発依存関係

開発中にだけ必要なツールを、開発用の枠に入れます。テスト、ビルド、型検査、ドキュメント生成などが該当します。アプリの実行時には不要なので、配布サイズや依存の整理に役立ちます。

B. –save-optional または -O：オプションの依存関係

あってもなくても動く機能を、オプション扱いにします。実行環境によっては入らないこともあります。ベースの機能は保ちつつ、対応できる環境では追加機能を活かせます。利用有無が分かるように、説明を残しておくと親切です。

C. –save-exact または -E：バージョン固定

依存のバージョンを、より厳密に固定します。細かな差分で挙動が変わってほしくないときに使います。チームで再現性を最優先にしたい場合や、検証済みの状態を長く維持したいときに効果があります。

よくある質問：–save と –save-dev の混在は問題？

同じパッケージを両方の枠で同時に入れるのは避けます。どちらの用途かを先に決め、片方にそろえると混乱が減ります。迷うときは「本番実行に必要かどうか」で考えると、分類がしやすくなります。

よく使うオプションの比較表

使い分けの判断基準とチェックリスト

ここまでの内容を、意思決定の手順に落とします。誰が使うか、いつ必要か、どこで動くかの三つを見れば、ほとんどの場面で迷いません。チームで共有できる短いメモにすると、運用のばらつきが少なくなります。

• 誰が使うか：プロジェクト外でも使うならグローバル、内だけならローカル。
• いつ必要か：本番実行に必要なら依存、本番不要なら開発依存。
• どこで動くか：環境によって有無が変わるならオプション依存を検討。
• どれだけ固定するか：再現性を重視するなら、厳密なバージョン指定を含めます。
• 共有方法：プロジェクトのスクリプトやREADMEに実行方法を残します。

よくある質問：チームで統一するならどこをルール化すべき？

分類の基準、バージョンの固定方針、実行方法の書き方の三点が効果的です。ツールの更新タイミングも合わせて決めておくと、突然の差分で困りにくくなります。小さく始め、必要に応じて細かくしていくと定着しやすいです。

まとめ

大切なのは、使う場所と目的で選ぶことです。CLIをどこでも使いたいならグローバル。アプリに必要な依存はローカル。開発だけの道具は開発依存へ。環境で異なる機能はオプションへ。再現性が要るなら固定を強めます。迷ったら、まずはローカルに入れてプロジェクトで管理し、必要性が明らかなものだけグローバルに広げると混乱が減ります。

よくある質問：まず迷ったらどちらを選べば安全？

最初はローカルに入れて、プロジェクト内で実行できる形にするのが無難です。運用してみて、複数プロジェクトで同じCLIを頻繁に使うと分かったら、グローバルも検討します。判断の理由を記録しておくと、後からの見直しが簡単です。