npmはNode.jsの公式パッケージマネージャで、Isaac Z. Schlueter氏が2010年1月に最初のバージョンを公開しました。クライアントツール（コマンドラインのnpm）と中央レジストリ（npmjs.com）の2つから構成され、後者はGitHub社が2020年に買収した現在も世界最大規模のソフトウェアパッケージ配信基盤です。Node.js本体に同梱して配布されているためインストール不要で誰でも使え、登録パッケージ数・週次ダウンロード数ともに他言語のレジストリを大きく凌ぐ規模で、JavaScript/TypeScriptエコシステムの中核として今も機能しています。
この記事の目次
- package.jsonとpackage-lock.json
- publishとレジストリ運用
- 監査・ワークスペース・npxの活用
- Yarn・pnpm・Bunとの位置取り
- まとめ
package.jsonとpackage-lock.json
npmプロジェクトの設定はpackage.jsonに集約され、"dependencies": { "express": "^4.19.0" }のようにSemVer範囲指定で依存を書きます。"devDependencies"にはテストやビルド用のライブラリ、"scripts"には"start": "node server.js"のようなショートカットコマンドを書き、npm run startで実行できます。後者はプロジェクト共通の便利コマンド集として広く活用され、README代わりに使われることも珍しくありません。
package-lock.jsonはnpm 5（2017年）から導入された再現性確保のためのファイルで、解決後の正確な版数とハッシュを記録します。Gitにコミットして、npm ciコマンドでlockfile通りに依存を導入することで、開発機・CI・本番の依存を完全に一致させる運用ができます。lockfileが導入される以前は同じpackage.jsonでも環境ごとに微妙に違うバージョンが入る問題があり、Yarnの登場がnpmにlockfile実装を促した経緯があります。
publishとレジストリ運用
新規パッケージはnpm initで雛形のpackage.jsonを作り、ソースを実装後にnpm loginでnpmjs.comへログイン、npm publishで公開できます。公開後の版数は不変扱いで、誤って公開した版はnpm unpublishまたはnpm deprecateで取り下げ・非推奨化できますが上書きはできません。2016年のleft-pad事件（作者が11行のライブラリを削除して世界中のビルドが壊れた騒動）以降は、unpublishに72時間制限が設けられるなどルールが厳格化されています。
scoped packageと呼ばれる@org/name形式を使うと、組織やユーザー単位の名前空間内にパッケージを配置でき、企業のプライベートレジストリと公開レジストリを混在させた運用が可能です。Microsoft・Google・Meta・Vercelなど多くの企業がscopedで公開しており、npmジャック（既存有名パッケージへのなりすまし）対策にも有効です。GitHub Packagesや社内Nexusと組み合わせれば、社内向けと公開向けを同じnpm CLIで切り替えながら扱えます。
監査・ワークスペース・npxの活用
npm auditはnpmjs.comが配信する脆弱性データベースと依存ツリーを照合し、影響のあるパッケージとSemVer的に取れる修正版を提示する機能です。GitHub Advisory Databaseと連携しており、CIでnpm audit --audit-level=highを実行すれば重大な脆弱性が混入した時点でビルドを失敗させる運用が可能です。巨大プロジェクトでは依存ツリーが深く、警告が大量に出ることもあるため、Dependabotやpnpm/Yarnの監査機能と組み合わせて運用するチームが多くなっています。
npm 7（2020年）からはWorkspacesが正式サポートされ、ルートのpackage.jsonに"workspaces": ["packages/*"]と書けばモノレポ運用が可能になりました。npxは2017年にnpm 5.2と同時に追加された機能で、ローカルにインストールしたCLI（例：npx eslint）やレジストリから一時実行するパッケージ（例：npx create-react-app my-app）を扱える点で開発体験を大きく変えました。package.jsonの"engines": { "node": ">=20" }でNode版数を制約できるため、本番環境とのバージョン乖離も最小限に抑えられます。
Yarn・pnpm・Bunとの位置取り
npmは2016年にYarn、2017年にpnpm、2022年にBunと、相次ぐ競合の登場で何度も「終わりだ」と言われながら改善を重ね、今も最大のシェアを保っています。公式同梱の安心感とnpmjs.com統合の利便性、フィードバックを受けた継続的な改良（lockfile・Workspaces・npx）が支持の理由です。Yarn・pnpm・Bunもnpmレジストリを共有して動いているため、ツールを変えても基盤はnpmという構図が続いています。
とはいえ性能・モノレポ運用・厳格な依存管理が要件なら、pnpmやYarn Berryに分があるのも事実です。新規プロジェクトを始めるときは「迷ったらnpm、こだわりがあればpnpm、特殊要件があればYarn Berry・Bun」と整理すると判断がぶれにくく、移行コストも最小化できます。Node.jsエコシステムを使う限りnpmレジストリとの付き合いは避けられず、ツールがどれであれnpmの基本的な仕組みを理解しておくのが必須教養と言えます。
まとめ
npmは2010年にIsaac Z. Schlueter氏が公開したNode.js公式のパッケージマネージャで、Node.js同梱と巨大レジストリでJavaScript/TypeScriptエコシステムの中心に居座り続けています。package.json・package-lock.json・Workspaces・npx・auditといった機能を備え、競合の刺激を受けつつ着実に進化を続けてきました。Yarn・pnpm・Bunと選び分けを意識しつつ、Node開発の基礎教養としてnpmを理解しておくことが最も再現性の高い投資になります。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント