はじめに

仕事で初めて pnpm を利用したので、理解のために自分でもやってみました。

Qiita用にJavaのエコシステム（MavenやGradle）と比較しながら理解してみました。

フロントエンドのパッケージ管理の全体像

概念・役割	Javaの世界	フロントエンドの世界
パッケージ管理ツール	Maven, Gradle	npm, Yarn, pnpm
設定ファイル	`pom.xml`, `build.gradle`	`package.json`
依存関係の固定	なし（または各種プラグイン等）	`package-lock.json`, `pnpm-lock.yaml`
ライブラリの実体保存先	`~/.m2/repository`（グローバル）	`node_modules/`（プロジェクト毎）
中央リポジトリ	Maven Central	npm registry

AIからの補足

package.json: プロジェクトの心臓部。Mavenの pom.xml のように、依存関係やビルドスクリプトを記述します。Javaでいう test のように、本番用（dependencies）と開発用（devDependencies）を分けて書きます
node_modules: ライブラリの実体が保存されるフォルダ。Javaの .m2 と違い、プロジェクトごとに作成されます
Lockファイル: チーム開発で環境差異を防ぐための、依存ツリーの正確なバージョン記録ファイル
現在使われている主なツールは「npm」「Yarn」「pnpm」の3種類です

「pnpm」がnpmの課題を解決

npmの課題

ディスク容量の圧迫: プロジェクトごとに node_modules へライブラリを丸ごとコピーするため、同じReactのファイルがPC内に大量に複製され、ストレージを圧迫する
ファントム依存関係: パスを短くするため依存関係をフラットに配置しており、package.json に明記していない孫依存ライブラリまで誤ってインポートできてしまう

pnpmの解決策（グローバルストアとシンボリックリンク）

pnpmは、PC上の共通領域（グローバルストア）にライブラリの実体を1つだけ保存し、各プロジェクトには「ハードリンク」を張ります。
これは、JavaのMavenが ~/.m2/repository にJarファイルをキャッシュし、各プロジェクトからそれを参照する仕組みと非常に似ています。これにより、ディスク容量を劇的に節約できます。
また、シンボリックリンクを使って本来の依存ツリーを厳格に構築するため、隠れたバグ（ファントム依存関係）も防ぎます。

パッケージマネージャーを管理する「Corepack」

Corepackは、「パッケージ管理ツール（pnpmやYarn）自体のバージョン」をプロジェクトごとに固定・管理するためのツールです。
Javaエンジニアへの一番わかりやすい例えは、「Gradle Wrapper (gradlew)」や「Maven Wrapper (mvnw)」のフロントエンド版です。

チーム開発で「Aさんはpnpm v8、Bさんはv9」のようにバージョンがバラバラだと、Lockファイルのコンフリクトが頻発します。
Corepackを使うと、package.json に以下のようにバージョンを指定できます。

{
  "name": "my-project",
  "packageManager": "pnpm@9.5.0"
}

【重要】Node.js v25以降の最新事情
かつてCorepackはNode.jsに標準同梱されていましたが、Node.js v25以降では本体から外されました（アンバンドル化）。そのため、最新環境では最初に npm install -g corepack で手動インストールする必要があります。

pnpmでプロジェクトの初期化（ハンズオン）

pnpm + Corepack + Vite を組み合わせて初期化

Step 1: Corepackの有効化

# Node.js v25以降の場合は事前に npm install -g corepack を実行
corepack enable

Step 2: Viteを使ったプロジェクトの作成

Javaでいう 'mvn archetype:generate' で雛形作成

pnpm create vite@latest my-frontend-app
# （対話形式でReact/Vueなどのフレームワークを選択）

Step 3: プロジェクトへの移動とバージョンの固定（Corepack）

作成したフォルダに移動して、このプロジェクトで使用するpnpmを固定

cd my-frontend-app

# 最新のpnpmバージョンに固定（package.jsonに自動追記される）
corepack use pnpm@latest

Step 4: 依存関係のインストールと起動

# ライブラリのインストール（pnpmの恩恵で超高速！）
pnpm install

# 開発用ローカルサーバーの起動
pnpm dev

起動後、ターミナルに表示される http://localhost:5173/ へアクセスすれば完了。

ここで叩いた 'pnpm dev' などのコマンドは 'package.json' の "scripts" に定義されていて、Mavenの 'mvn spring-boot:run' やGradleのタスクのように機能します。

おわりに

私のようなJava経験者向けに無理やり、JavaのMavenなどと比較して記載してみましたが、一番しっくりきたのはAIに出してもらった下記の「npmとのコマンド比較」でした。

補足：AI

npmとのコマンド比較

目的・利用シーン	npm (従来)	pnpm (モダン)
プロジェクトの全パッケージをインストール	`npm install` (または `npm i`)	`pnpm install` (または `pnpm i`)
本番用パッケージを追加	`npm install <pkg>`	`pnpm add <pkg>`
開発用パッケージを追加 (※テストツール等)	`npm install -D <pkg>`	`pnpm add -D <pkg>`
パッケージを削除	`npm uninstall <pkg>`	`pnpm remove <pkg>` (または `pnpm rm`)
パッケージを更新	`npm update <pkg>`	`pnpm update <pkg>` (または `pnpm up`)
スクリプトの実行 (例: dev, build)	`npm run dev`	`pnpm dev` (※ `run` は省略可能)
使い捨てコマンドの実行 (※1)	`npx <コマンド>`	`pnpm dlx <コマンド>`
ローカルコマンドの実行 (※1)	`npx <コマンド>` または `npm exec`	`pnpm exec <コマンド>`

Javaエンジニア向けの重要なポイント（コマンドの違い）

install ではなく add を使う

npmではパッケージを追加する際も npm install <パッケージ名> を使っていましたが、pnpmでは pnpm add <パッケージ名> を使います。
これは、Java（Maven）で言うところの「pom.xml にを追加する（add）」作業と、「プロジェクト全体の依存関係をダウンロードして配置する（install）」作業が、意味合いとして明確に分離されたためです。

魔法のコマンド npx の代替（pnpm dlx と pnpm exec）

ネット上のフロントエンドの記事を読んでいると、頻繁に npx というコマンドが登場します（例：npx create-react-app など）。これは「パッケージをインストールせずに、一時的にインターネットからダウンロードして一回だけ実行する」という便利なコマンドです。
pnpm環境でこれに相当することを行いたい場合は、用途に応じて以下のように使い分けます。

pnpm dlx: 手元のプロジェクトにないパッケージを、一時的にダウンロードして1回だけ実行したい場合（ダウンロードして実行（download and execute）の略）
pnpm exec: すでにプロジェクト内（node_modules内）にインストールされているパッケージのコマンドを実行したい場合

参考（感謝）

AIに聞きながら