結論

開発環境では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を実行
↓

package.json

"dependencies":{
	X: "^1.0.0"　←　1.x.x に該当する最新のバージョン
}

その後、Xが1.0.1にupgradeされた後に
本番デプロイ時にnpm install X --saveを実行
↓

package.json

"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、デプロイ時の時間短縮について検証したいです。

参考

宣伝させてください！