結論
開発環境ではnpm i
本番環境、CI/CD時にはnpm ci
解説 npm i とnpm ciの違い
npm install X --saveを実行すると、以下のようにパッケージXとその依存関係であるYがインストールされます。
Xの最新バージョンが 1.0.0とする
X
└─ Y
開発環境でnpm install X --saveを実行
↓
"dependencies":{
X: "^1.0.0" ← 1.x.x に該当する最新のバージョン
}
その後、Xが1.0.1にupgradeされた後に
本番デプロイ時にnpm install X --saveを実行
↓
"dependencies":{
X: "^1.0.1"
}
これだと本番環境と開発環境のバージョンが異なってしまう、本番環境デプロイ時には同じバージョン 1.0.0の X をインストールできるようにしたい!
↓
package.jsonのdependenciesを、 "X": "1.0.0"
にすれば、Xのバージョンは 1.0.0
になりそう。
しかし、これでは開発環境を再現できない
理由)
Xの 1.0.0
の package.jsonには、 次のような dependencies が書かれている可能性がある。
"Y": "^1.0.0"
Yの別のバージョン1.1.0
が公開されているかもしれない。
↓
package-lock.json
というのが、基本的にはこの node_modules
ディレクトリを完全再現することが可能
しかし、package.jsonがあってもnpm installで上書きされる可能性がある
理由)
npmのバージョンによる微妙な npm install
の挙動の違いや、様々なユースケース、人為的なミス
package-lock.json
から node_modules
ディレクトリを構築したい
npm install
はそれを保証してない
本番デプロイ時のパッケージのインストールにはnpm ciを使う(CIはClean Installの略)
以下簡単な処理の流れ
1. node_modules ディレクトリの削除
2. package-lock.json と package.json の整合性のチェック
3. package-lock.json から node_modules を再現
パッケージのアップデート/追加にはnpm iを使う
package-lock.json
を更新することができる npm install
や npm update
などを使う
アップデート後にはメンバーにnpm iするように依頼しましょう
展望
次はGitHub Actions上でのtest、デプロイ時の時間短縮について検証したいです。
参考
- あなたがnpm installをしてはいけない時
- そろそろ適当に npm install するのを卒業する
- そもそもnpmからわからない
- npm installとnpm ciの違い
- difference-between-npm-i-and-npm-ci-in-node-js
- npm i vs npm ci: install node modules in your app faster and wisely
- npm install と npm ci って結局どう使うの?2023年版
宣伝させてください!