@ledsun blog

Hのキーがhellで、Sのキーがslaveだ、と彼は思った。そしてYのキーがyouだ。

lockfileVersion が変わった package-lock.jsonをコミットする?する

npm 7 で package-lock.json のフォーマットが変わりました。 lockfileVersion の値が1から2になりました。

それ以来「フォーマットが変わった pakcage-lock.json をコミットしたら、npm 6を使っているユーザーはnpm パッケージを使えなくなる?」という疑問を持っていました。 特に試したことがなかったのですが、確認できました。

結論

結論からいうと、lockfileVersionが2のpakcage-lock.jsonがある状態でもnpm 6は使えます。 lockfileVersionが2のpakcage-lock.jsonがある状態ででnpm installコマンドを実行すると、lockfileVersionが1のpakcage-lock.jsonが作り直されます。 Node.js 12.22.4についてくるnpm 6.14.14をインストールして試しました。

また、Github Actionsの actions/setup-node@v2 を動かすには pakcage-lock.json が必要です。 CIを動かす場合にはコミットしておいた方が良さそうです。 ですが、https://github.com/eslint/eslintは、package-lock.jsonをコミットせずにGithub AcitonsでCIを回しています。 回避方法はありそうです。

f:id:ledsun:20210807040311p:plain
package-lock.jsonがなくてGithub Actionsのaction/setup-node@v2が失敗する様*1

背景

engineering.mobalab.net

、package-lock.jsonもGit管理に含めることによって先述したようにインストールされるパッケージのバージョンを固定することができ、それぞれの開発者の環境でpackage-lock.jsonに指定されたバージョンの環境をnpm installによって再現することができるからです。

と、あるように、package-lock.jsonのコミットが推奨されているということは知っていました。 実際コミットして運用していました。 npm 7になったときに知識の更新ができていませんでした。 npmパッケージの開発者としては常に最新を使っておけばいいのですが、ユーザーにとってどうなるのか気になっていました。

蛇足

npmにpackage-lock.jsonが導入されたバージョン(v5.0.0)の後のいくつかのバージョンでは、不必要にpackage-lock.jsonがアップデートされてしまったり

すっかり忘れていました。 確かにこの謎現象ありました。 なんでロックファイルなのに?npm installで更新されるんだろう?と不思議に思った記憶があります。 いまは、全然こういう不可解な動きはしていないです。

参考