package-lock.jsonの役割は何ですか？

npm @ 5が公開されました。混乱を招く新機能package-lock.jsonファイル（後npm install）があります。知りたいのですが、このファイルの効果は何ですか？

package.json自体のようにスター付きのバージョン管理を使用するのではなく、正確なバージョン管理された依存関係ツリーを格納します（例：1.0。*）。これは、他の開発者や製品リリースなどの依存関係を保証できることを意味します。これには、ツリーをロックするメカニズムもありますが、通常、package.jsonが変更されると再生成されます。

npm docsから：

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

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

チームメイト、デプロイメント、継続的インテグレーションがまったく同じ依存関係を確実にインストールできるように、依存関係ツリーの単一の表現を説明します。

ユーザーがディレクトリ自体をコミットする必要なく、node_modulesの以前の状態に「タイムトラベル」する機能を提供します。

読みやすいソース管理の差分を使用して、ツリーの変更の可視性を高める。

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

編集する

正確なバージョン番号を指定したpackage.jsonの使用に関するjrahhaliの質問に回答するには package.jsonには直接の依存関係のみが含まれ、依存関係の依存関係（ネストされた依存関係とも呼ばれる）は含まれないことに注意してください。これは、標準のpackage.jsonでは、それらのネストされた依存関係のバージョンを制御できず、それらを直接参照するか、ピア依存関係が役に立たないため、直接の依存関係がこれらのネストされた依存関係に対して定義するバージョン許容値も制御できないためです。

直接の依存関係のバージョンをロックダウンしても、完全な依存関係ツリーが毎回同じであることを100％保証することはできません。次に、直接の依存関係の（セマンティックバージョニングに基づく）互換性のない変更を許可すると、ネストされた依存関係をさらに制御できなくなり、直接の依存関係がセマンティックバージョニングルールに違反しないことを保証できなくなります。自分自身。

これに対するすべての解決策は、上記のように完全な依存関係ツリーのバージョンでロックするロックファイルです。これにより、他の開発者またはリリースの依存関係ツリーを保証しながら、標準のpackage.jsonを使用して新しい依存関係バージョン（直接または間接）のテストを許可できます。

NB。以前のシュリンクラップjsonはほとんど同じことを行いましたが、ロックファイルは機能を明確にするために名前を変更しています。プロジェクトにすでにシュリンクラップファイルがある場合は、ロックファイルの代わりにこれが使用されます。

これはnpmにとって非常に重要な改善です。すべてのパッケージのまったく同じバージョンを保証します。

異なる環境の異なる時間に同じパッケージでプロジェクトをビルドする方法を教えてください。たとえば、で使用^1.2.3したりpackage.json、一部の依存関係がそのように使用しているとnpm installしますが、開発マシンとビルドサーバーで毎回同じバージョンを取得できるようにするにはどうすればよいですか？package-lock.jsonはそれを保証します。

npm installビルドサーバーまたはデプロイメントサーバー上でロックファイルを再生成しますnpm ci（ロックファイルから読み取り、パッケージツリー全体をインストールします）。

package-lock.json「バージョン」プロパティなどのプロパティの数値、または依存関係プロパティがで変更されたときに書き込まれpackage.jsonます。

これらの数値でいる場合package.jsonとpackage-lock.json一致し、package-lock.jsonから読み込まれます。

これらの数値でいる場合package.jsonとpackage-lock.json一致しない場合は、package-lock.jsonそれらが存在する場合、これらの新しい値、および、そのようなキャレットやチルダなどの新しい修飾子とに書き込まれます。しかし、への変更を引き起こしているのは数字ですpackage-lock.json。

意味を確認するには、次のようにします。package.jsonなしpackage-lock.jsonで使用し、次で実行npm install：

{
  "name": "test",
  "version": "1.0.0",
  ...
  "devDependencies": {
    "sinon": "7.2.2"
  }
}

package-lock.json 今持っているでしょう：

"sinon": {
  "version": "7.2.2",

次に、両方のファイルを新しいディレクトリにコピーして貼り付けます。package.json（キャレットの追加のみ）に変更します。

{
  "name": "test",
  "version": "1.0.0",
  ...
  "devDependencies": {
    "sinon": "^7.2.2"
  }
}

実行しますnpm install。package-lock.jsonファイルがない場合、sinon @ 7.3.0がインストールされます。npm installれからの読み取り package-lock.jsonおよび7.2.2をインストールします。

次に変更package.json：

{
  "name": "test",
  "version": "1.0.0",
  ...
  "devDependencies": {
    "sinon": "^7.3.0"
  }
}

実行しますnpm install。package-lock.jsonはに書き込まれ、次のように表示されます。

"sinon": {
  "version": "^7.3.0",

同様に言及すべき重要なことの1つは、パッケージロックファイルに伴うセキュリティの向上です。誰かがパブリックnpmレジストリを改ざんし、パッケージ自体のバージョンを変更することなくパッケージのソースコードを変更した場合、パッケージのすべてのハッシュを保持するため、パッケージロックファイルによって検出されます。

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

チームメイト、デプロイメント、継続的インテグレーションがまったく同じ依存関係を確実にインストールするように、依存関係ツリーの単一の表現を記述します。これには、次のプロパティが含まれています。

    {
"name": "mobileapp",
"version": "1.0.0",
"lockfileVersion": 1,
"requires": true,
"dependencies": {
"@angular-devkit/architect": {
  "version": "0.11.4",
  "resolved": "https://registry.npmjs.org/@angular- devkit/architect/-/architect-0.11.4.tgz",
  "integrity": "sha512-2zi6S9tPlk52vyqNFg==",
  "dev": true,
  "requires": {
    "@angular-devkit/core": "7.1.4",
    "rxjs": "6.3.3"
  }
},

}

このファイルはnpmによって自動的に作成および使用され、パッケージのインストールを追跡し、プロジェクトの依存関係の状態と履歴をより適切に管理します。このファイルの内容は変更しないでください。

package-lock.json：アプリケーションに現在インストールされている正確なバージョンの詳細が含まれています。