npm 5で作成されたpackage-lock.jsonファイルをコミットしますか？

npm 5が本日リリースされ、新機能の1 つには、package-lock.jsonファイルの作成による確定的なインストールが含まれます。

このファイルはソース管理に保持されることになっていますか？

私はそれがyarn.lockand composer.lockに似ていると想定していますが、どちらもソース管理に保持されることになっています。

はい、package-lock.jsonソース管理にチェックインすることを目的としています。npm 5を使用している場合は、コマンドラインに次のようcreated a lockfile as package-lock.json. You should commit this file.に表示されることがありnpm help package-lock.jsonます。

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

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

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

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

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

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

主要な詳細の1つpackage-lock.jsonは公開できないことであり、トップレベルパッケージ以外の場所で見つかった場合は無視されます。それはnpm-shrinkwrap.json（5）とフォーマットを共有します。これは基本的に同じファイルですが、公開を許可します。これは、CLIツールをデプロイするか、本番パッケージを作成するための公開プロセスを使用しない限り、お勧めできません。

両方の場合package-lock.jsonやnpm-shrinkwrap.jsonパッケージのルートに存在している、package-lock.json完全に無視されます。

はい、チェックインすることを目的としています。独自のコミットを取得することをお勧めします。これにより、差分に多くのノイズが追加されることがわかります。

はい、あなたはすべきです：

1. をコミットしpackage-lock.jsonます。
2. npm cinpm installCIとローカル開発マシンの両方でアプリケーションをビルドするときの代わりに使用する

npm ciワークフローが必要との存在をpackage-lock.json。

npm installコマンドの大きな欠点は、予期しない動作であり、それがを変更する可能性がpackage-lock.jsonあるのに対しnpm ci、ロックファイルで指定されたバージョンのみを使用してエラーを生成することです。

• package-lock.jsonとpackage.jsonが同期していない場合
• package-lock.jsonが欠落している場合。

したがって、npm installローカルで実行されます。複数の開発者がいる大規模なチームでpackage-lock.jsonは、package-lock.json代わりに完全に削除することを決定するために、開発者内で多くの競合が発生する可能性があります。

しかし、プロジェクトの依存関係がさまざまなマシン間で信頼できる方法で繰り返し解決されると信頼できる強力なユースケースがあります。

package-lock.jsonあなたからそれを正確に得る：既知の作業状態。

以前は、ランダムな依存関係が破壊的な更新を取得したために、いつかビルドが失敗するpackage-lock.json/ npm-shrinkwrap.json/ yarn.lockファイルのないプロジェクトがありました。

最後に機能するバージョンを推測する必要がある場合があるため、これらの問題は解決が困難です。

新しい依存関係を追加する場合でも、を実行しnpm install {dependency}ます。アップグレードする場合は、npm update {dependency}またはnpm install ${dependendency}@{version}を使用して、変更されたをコミットしpackage-lock.jsonます。

アップグレードが失敗した場合は、最新の既知の動作に戻すことができますpackage-lock.json。

npm docを引用するには：

生成されたパッケージロックをソース管理にコミットすることを強くお勧めします。これにより、チームの他の誰でも、デプロイメント、CI /継続的インテグレーション、パッケージソースでnpm installを実行する誰でも、まったく同じ依存関係ツリーを取得できます。あなたが開発していたこと。さらに、これらの変更の差分は人間が読める形式であり、npmがnode_modulesに加えた変更を通知します。そのため、推移的な依存関係が更新されたり、巻き上げられたりしたかどうかを確認できます。

とvsの違いnpm cinpm installに関して：

• プロジェクトには、既存のpackage-lock.jsonまたはnpm-shrinkwrap.jsonが必要です。
• パッケージロックの依存関係がpackage.jsonの依存関係と一致しない場合、 npm ciを更新する代わりにエラーで終了します。
• npm ci 一度にインストールできるのはプロジェクト全体のみです。このコマンドを使用して個々の依存関係を追加することはできません。
• node_modulesが既に存在する場合npm ciは、インストールを開始する前に自動的に削除されます。
• package.jsonパッケージロックやパッケージロックへの書き込みは行われません。インストールは基本的にフリーズされます。

注：私はここに同様の答えを投稿しました

はい、チェックインすることをお勧めします（はい、チェックイン）

差分を見たときに多くのノイズや競合が発生することに同意します。しかし、利点は次のとおりです。

1. すべてのパッケージのまったく同じバージョンを保証します。この部分は、異なる環境で異なる時間にビルドする場合に最も重要です。で使用することもでき^1.2.3ますがpackage.json、npm install開発マシンとビルドサーバー、特に間接依存パッケージで同じバージョンを毎回確実に取得するにはどうすればよいですか？まあ、それpackage-lock.jsonを保証します。（npm ciロックファイルに基づいてパッケージをインストールする助けを借りて）
2. インストールプロセスが改善されます。
3. 新しい監査機能に役立ちますnpm audit fix（監査機能はnpmバージョン6からのものだと思います）。

私のプロジェクトではこのファイルをコミットしません。ポイントは何ですか ？

1. 生成されます
2. gitlab-ci.ymlビルドを使用したgitlabでのSHA1コード整合性エラーの原因です

私はそれについて悪い経験をしたので、libsのpackage.jsonで^を決して使用しないことは事実です。

git diffを実行するときのノイズについて不平を言う人々に：

git diff -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'

私がしたことはエイリアスを使用することでした：

alias gd="git diff --ignore-all-space --ignore-space-at-eol --ignore-space-change --ignore-blank-lines -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'"

リポジトリ全体（それを使用するすべての人）のdiffにあるpackage-lock.jsonを無視するには、これをに追加し.gitattributesます。

package-lock.json binary
yarn.lock binary

これにより、「バイナリファイルa / package-lock.jsonとb / package-lock.jsonは、パッケージロックファイルが変更されるたびに異なります。さらに、一部のGitサービス（特にGitLabではなくGitHub）も除外されます。これを行うときにオンラインで表示すると、差分からこれらのファイル（変更された10k行はありません！）

はい、このファイルをコミットできます。NPMの公式ドキュメント：

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

このファイルは、ソースリポジトリにコミットすることを目的としています[。]

package-lock.jsonをグローバルに無効化

端末に次のように入力します。

npm config set package-lock false

これは本当に魔法のように私のために働く

はい、package-lock.jsonをコミットするのは標準的な方法です

package-lock.jsonをコミットする主な理由は、プロジェクトの全員が同じパッケージバージョンを使用しているためです。

長所：-

• 厳密なバージョン管理に従い、メジャーバージョンへの更新を自動的に許可しない場合、サードパーティパッケージの下位互換性のない変更からパッケージロックをコミットすることで、多くの助けになります。
• 特定のパッケージを更新した場合、package-lock.jsonで更新され、リポジトリを使用するすべてのユーザーが変更をプルすると、その特定のバージョンに更新されます。

短所：-

• それはあなたのプルリクエストを醜く見せることができます:) '

編集：-npm installは、プロジェクト内の全員が同じパッケージバージョンにあることを確認しません。npm ciはこれに役立ちます。

私のnpmの使用は、縮小化/醜化されたcss / jsを生成し、djangoアプリケーションが提供するページで必要なJavaScriptを生成することです。私のアプリケーションでは、JavaScriptがページ上で実行されてアニメーションを作成し、時にはAjax呼び出しを実行し、VUEフレームワーク内で動作し、CSSで動作します。package-lock.jsonがpackage.jsonの内容をオーバーライドする制御を持っている場合、このファイルの1つのバージョンが必要になる場合があります。私の経験では、npm installによってインストールされる内容に影響を与えないか、影響を与える場合でも、私が知っている限り、私が展開するアプリケーションに悪影響を与えていません。mongodbや、従来のシンクライアントである他のアプリケーションは使用しません。

npm installがこのファイルを生成し、npm installがアプリを実行する各サーバーのデプロイプロセスの一部であるため、package-lock.jsonをリポジトリから削除します。ノードとnpmのバージョン管理は各サーバーで手動で行われますが、同じになるように注意しています。

場合はnpm install、サーバー上で実行され、それがパッケージlock.jsonを変更し、サーバ上のレポで記録されたファイルに変更がある場合は、次の展開では、原点からの新しい変更をプルすることを可能に文句を言いません。つまり、プルはpackage-lock.jsonに加えられた変更を上書きするため、デプロイできません。

ローカルで生成されたpackage-lock.jsonをリポジトリの内容（ハードオリジンマスターのリセット）で上書きすることもできません。package-lock.jsonが内容を反映していない場合にコマンドを発行すると、npmが文句を言うからです。 npmインストールが原因でnode_modulesが発生し、デプロイが中断されます。これがnode_modulesにわずかに異なるバージョンがインストールされていることを示している場合は、問題が発生することはありません。

node_modulesがリポジトリ上にない場合（および存在しない場合）、package-lock.jsonは無視する必要があります。

何か不足している場合は、コメントで訂正してください。ただし、このファイルからバージョン管理が行われているという点は意味がありません。ファイルpackage.jsonにはバージョン番号が含まれており、このファイルはnpm installが発生したときにパッケージをビルドするために使用されるファイルであると想定しています。

jason@localhost:introcart_wagtail$ rm package.json
jason@localhost:introcart_wagtail$ npm install
npm WARN saveError ENOENT: no such file or directory, open '/home/jason/webapps/introcart_devtools/introcart_wagtail/package.json'

ビルドは失敗しますが、node_modulesをインストールしたり、js / cssをビルドするためにnpmを適用したりしても、package-lock.jsonを削除しても問題はありません

jason@localhost:introcart_wagtail$ rm package-lock.json 
jason@localhost:introcart_wagtail$ npm run dev

> introcart@1.0.0 dev /home/jason/webapps/introcart_devtools/introcart_wagtail
> NODE_ENV=development webpack --progress --colors --watch --mode=development

 10% building 0/1 modules 1 active ...