package-lock.json についてわかりやすく言語化する
shibaです。
突然ですが、デザイナーからこんな質問をいただきました。
package-lock.json が勝手に変更されるんだけど Ignore していいの？
Gemfile.lock が勝手に変更されたから消しちゃっていい？
なんか起動しなくなったから package-lock.json と node_modules 消して npm i しようかな？
結論だけ言うと「ダメです」で終わってしまうんですが、どうしてダメなのかを非エンジニアに説明するのは地味に難しいです。
タイトルでは npm を使っている場合の package-lock.json に触れましたが、 Gemfile.lock や yarn.lock など lockファイルは近年の開発環境では常に横にある存在です。
npm 利用時には package.json と package-lock.json というファイルがお供になりますが、それぞれの役割を知っていれば上記のような質問は発生しないでしょう。
というわけで、今回はこの lock ファイルの役割をできるだけわかりやすく言語化してみます。
それではペペロンチーノを作っていきます
A「ペペロンチーノを作るのでこれ買ってきて」メモを渡す
買い出しリスト
ぺぺの材料
・にんにく
・唐辛子
・オリーブオイル
・イタリアンパセリ
・パスタ（1.6mm以上のやつ！）
B「ほいほい」メモ受け取ってスーパーへ
🚲…
B「にんにく国産のやつと外国産のやつあるな、適当に国産で」（国産にんにく5個入 かごにin）
B「唐辛子は輪切りのと一本のやつあるけど輪切りでいいよね」（輪切り唐辛子 かごにin)
B「オリーブオイル、安いのから高いのまで色々有るな。気分でこれ」（ちょっといいオリーブオイル かごにin）
B「パセリは振りかけるやつだろうからこれかな」（SBパセリ乾燥 かごにin）
B「パスタは1.6mm以上ね…これでええか」（バリラ No.5 1.78mm かごにin）
B「お会計〜」
店員さん「まいど」レシート渡す
B「ども」レシートもらう
レシート
国産にんにく5個パック ¥200
輪切り唐辛子 ¥150
ちょっといいオリーブオイル ¥1200
SB パセリ 乾燥 ¥300
バリラ No.5 1.78mm ¥700
🚲…
B「買ってきたよ」
A「ありがと、飯作るわ」
買い出しメモとレシートの位置づけ
買い出しメモには欲しい物の条件が書かれていて、Bはその条件に合うように商品を選びました。
レシートはBが選んだ具体的な商品が記載されています。
もう一度全く同じ買い物をしようと思うとレシートが必須でしょうが、レシピの材料を毎回より良いものに検討するなら買い出しメモで十分ですね。
結論から言うと、
package.jsonやGemfileは買い出しメモ、package-lock.json、yarn.lock、Gemfile.lockなどのlockファイルはレシートに相当します。
買い出しメモ系
package.jsonやGemfileなど
必要なものの条件が記載されている
レシート系
package-lock.json、yarn.lock、Gemfile.lockなど
具体的に何を調達したかが記載されている
package.jsonやGemfileの中身を読んでみると、
"meu": "^4.15.4"のようにバージョンのところに「^」などの記号が含まれています。
これは「最初の数字（メジャーバージョン）が4のもので4.15.4より新しいもの」という意味です。
これより古いと欲しい機能がなかったりセキュリティが危うい、でも同じバージョンで動かし続けるとセキュリティ改善やバグ修正などの恩恵を受けられないためこのような記載になります。
とりあえずこれさえあれば各個人で開発に必要なモジュールのインストールができそうですね。
これに対してlockファイルには最低限バージョン番号、技術によっては具体的にどこから拾ってきたかなどの様々な情報が記載されます。
このファイルをもとにモジュールをインストールすれば直前に変更を加えた開発者と同じ環境がインストールできそうです。
lockファイルが勝手に変更される現象の正体
技術ごとに細かく変わるのでnpmを例に上げて話します。
開発環境構築に使われがちなnpm i（npm installの略コマンド）は、package.jsonを元にモジュールをインストールします。
買い出しメモだけ持って店に行くので、その場その場で条件に合う最新のものをインストールし、その内容をpackage-lock.jsonに更新します。
つまり、lockファイルの更新とはnpmなどのシステムが条件に合うより新しいものを見つけてきた結果です。
開発者はより新しいものを発見し、それを適用するかの判断が求められます。
lockファイルの使いどころ
主にCIや本番公開でのモジュールインストールに用いられます。
CIとは自動でコードが正常に挙動するかなどをチェックしたり公開処理したりするプログラムです。
CIや本番環境では開発者のように新しいものを適用するかどうかの判断ができないため、開発者が判断した具体的なモジュールをインストールする必要があるわけです。
CIや本番環境で勝手に開発環境と違うモジュールがインストールされると困りますよね。
npmの場合はnpm ciがlockファイルを元にインストールするコマンドに当たります。
lockファイルの扱いかた
最低限守りたいことは
直接編集しない
削除しない
変更があった場合は場合によって検討する
変更があった場合は賛否両論だと思います。
ぼくは挙動を確認して良さそうなら「RUN npm i」みたいなメッセージでコミットしてしまいます。
理想は変更が入ったモジュールの変更履歴を見て取り入れても大丈夫か確認することですね。
一応見なかったことにしてDependabotのPRを待つみたいな逃げ道もなくはないです。
もしあなたがエンジニアではなく判断が難しければ、エンジニアに判断を依頼していいと思います。
少しでもpackage-lock.jsonについての認識が明らかになれば幸いです。
読んでくださりありがとうございました。
株式会社Da Vinci Studio ではデザイナー、エンジニアともに積極採用中です。
よろしくお願いします！
参考
この記事が気に入ったらサポートをしてみませんか？