[解決済み] package-lock.jsonの役割は何ですか？

質問

npm@5が公開され、新機能が追加されました。 package-lock.json ファイル npm install ) が、私を混乱させます。このファイルの効果は何ですか？

解決方法は？

のようなスタードバージョニングを使用するのではなく、正確でバージョン管理された依存関係ツリーを保存します。 package.json そのものです(例: 1.0.*)。これは、他の開発者やプロッドリリースなどの依存関係を保証できることを意味します。また、ツリーをロックする仕組みもありますが、一般に、以下の場合に再生成されます。 package.json を変更します。

から npmのドキュメント :

package-lock.json は npm が node_modules ツリーか package.json を変更する操作に対して自動的に生成されます。これは生成された正確なツリーを記述しており、その後のインストールでは、途中の依存関係の更新に関係なく、同一のツリーを生成できるようになっています。

このファイルは、ソースリポジトリにコミットされることを意図しており、さまざまな目的に使用されます。

チームメイト、デプロイメント、継続的インテグレーションが全く同じ依存関係をインストールすることが保証されるような、依存関係ツリーの単一の表現を記述します。

ディレクトリ自体をコミットすることなく、node_modules の以前の状態に "タイムトラベルする機能を提供します。

ソースコントロールの差分を読みやすくすることで、ツリーの変更をより可視化すること。

また、以前にインストールされたパッケージに対して繰り返されるメタデータの解決をnpmがスキップできるようにすることで、インストールプロセスを最適化することができます。

編集

以下のjrahhaliさんの質問に対する答えですが、単に package.json を正確なバージョン番号で表示してください。あなたの package.json には直接の依存関係のみが含まれ、依存関係の依存関係 (ネストされた依存関係とも呼ばれます) は含まれません。つまり、標準の package.json また、直接の依存関係がネストした依存関係に対して定義するバージョンの許容範囲も制御できないので、ネストした依存関係を直接参照したりピア依存関係として参照したりしても役に立ちません。

直接の依存関係のバージョンをロックダウンしても、依存関係ツリー全体が毎回同一であることを100%保証することはできません。第二に、直接の依存関係を壊さないように（セマンティックバージョニングに基づいて）変更できるようにしたいと思うかもしれませんが、ネストした依存関係の制御はさらに難しくなり、直接の依存関係がある時点でセマンティックバージョニングルールを破らないという保証はまたできません。

これを解決するのがロックファイルで、上記のように完全な依存関係ツリーのバージョンをロックします。これにより、他の開発者やリリースのために依存関係ツリーを保証しながら、標準の package.json .

NB. 以前の npm-shrinkwrap.json はほとんど同じことをしていましたが、ロックファイルによって名前が変更され、機能が明確になりました。もし、プロジェクト内にシュリンクラップファイルが既にあれば、ロックファイルの代わりにこれが使用されます。