npm-shrinkwrap.jsonとpackage-lock.jsonの違いは何ですか？

では5 @ NPMのリリースで、それが今で書きますpackage-lock.jsonしない限り、npm-shrinkwrap.jsonすでに存在しています。

私はnpm @ 5をグローバルにインストールしました：

npm install npm@5 -g

そして今、a npm-shrinkwrap.jsonが次の間に見つかった場合：

npm install

警告が表示されます：

npm WARN read-shrinkwrap This version of npm
is compatible with lockfileVersion@1,
but npm-shrinkwrap.json was generated for lockfileVersion@0.
I'll try to do my best with it!

したがって、私の持ち帰りは、シュリンクラップをに置き換える必要があるということpackage-lock.jsonです。

しかし、なぜそれのための新しいフォーマットがあるのですか？何をすることができますpackage-lock.jsonことを行うnpm-shrinkwrap.jsonことができないのですか？

ファイルの内容はまったく同じですが、ドキュメントサイトで説明されているnpmリポジトリのドキュメントファイルでも説明されているように、npmによるファイルの処理方法にはいくつかの違いがあります。

• package-lock.json npmに公開されることはありませんが、 npm-shrinkwrapが、デフォルトでは
• package-lock.json トップレベルのパッケージにないファイルは無視されますが、依存関係に属するシュリンクラップファイルは尊重されます
• npm-shrinkwrap.jsonnpmバージョン2、3、4との下位互換性がありますがpackage-lock.json、npm 5+でのみ認識されます

を実行package-lock.jsonして、既存のものをに変換できnpm-shrinkwrap.jsonます。npm shrinkwrap。

したがって：

• パッケージをnpmに公開しない場合、これら2つのファイルのどちらを選択してもほとんど意味がありません。package-lock.jsonこれはデフォルトであり、その名前はnpm初心者にはわかりやすいので、使用することをお勧めします。あるいは、npm-shrinkwrap.json開発チームの全員がnpm 5+にいることを確認するのが難しい場合は、npm 2-4との下位互換性のために使用することもできます。（npm 5は2017年5月25日にリリースされました。後方互換性は、ほとんどの人が最終的にアップグレードするため、その日付から離れるほど重要性が低くなることに注意してください。）

• あなたがいる場合している NPMにあなたのパッケージを公開、あなたは間の選択肢があります。

  1. package-lock.jsonインストールした依存関係のバージョンを正確に記録するためにa を使用しますが、パッケージをインストールする人々は、package.json。
  2. を使用しnpm-shrinkwrap.jsonて、パッケージをインストールするすべての人がすべての依存関係のバージョンがまったく同じになることを保証します

  
  ドキュメントで（非常に簡潔に）説明されている公式の見解は、オプション1をライブラリに使用する必要があるということです（おそらく、パッケージの依存関係の多くが同じセカンダリ依存関係のわずかに異なるバージョンに依存している場合に発生するパッケージの重複の量を減らすためです）。ただし、そのオプション2は、グローバルにインストールされる実行可能ファイルには妥当な場合があります。

NPM開発者からの説明：

アイデアは、package-lock.jsonがシュリンクラップテクノロジーの最新かつ最高のものになること、そしてnpm-shrinkwrap.jsonが、正確なnode_modulesを備えたライブラリに非常に関心がある貴重な少数の人々のために予約されることです。 npm @> = 2を使用してCIで特定のツリーをインストールし、そのnpmバージョンをバンプする必要がない場合。

新しいロックファイル（ "package-lock.json"）は、基本的に同じコードをすべて共有し、npm-shrinkwrapとまったく同じ形式です（相互に名前を変更できます！）。それはコミュニティが理解しているようでもあります：「ロックファイルがあります」は人々と非常に速くクリックするようです。最後に、新しいファイルがあることで、親投稿で説明されているallow-publicationなどの奇妙なことをしなくても、shrinkwrapを使用して比較的低リスクの後方互換性を確保できました。

アイデアは--saveとシュリンクラップがデフォルトで発生するようにすることでしたが、不要な場所でシュリンクラップが発生する潜在的な問題を回避しました。したがって、競合を回避するために、新しいファイル名を付けただけです。npmの誰かがここでそれをより完全に説明しました：

https://www.reddit.com/r/javascript/comments/6dgnnq/npm_v500_released_save_by_default_lockfile_better/di3mjuk/

関連する引用：

npmはデフォルトでソースディレクトリにほとんどのファイルを公開し、人々は何年もシュリンクラップを公開しています。互換性を壊したくありませんでした。--saveとshrinkwrapをデフォルトで使用すると、誤ってそれを作成してレジストリを介して伝播するという大きなリスクがあり、基本的にdepとdedupeを更新する機能をレンダリングします... null。

そこで、新しい名前を選びました。そして突然、新しい名前を選びました。新しいロックファイルは基本的にすべて同じコード、まったく同じ形式を共有します