Npm 5で作成したpackage-lock.jsonファイルをコミットしますか？
npm 5が本日リリースされました そして新機能の1つにpackage-lock.jsonファイルの作成を伴う確定的インストールが含まれます。
このファイルはソース管理下に置かれるべきですか？
私はそれが yarn.lock と composer.lock に似ていると思っています。どちらもソース管理に保存されることになっています。
はい、package-lock.jsonはソース管理にチェックインされることを意図しています。 npm 5を使用している場合は、これがコマンドラインに表示されます。created a lockfile as package-lock.json. You should commit this file.npm help package-lock.json によると
npmが
package-lock.jsonツリーまたはnode_modulesのいずれかを変更する操作については、package.jsonが自動的に生成されます。中間の依存関係の更新に関係なく、後続のインストールで同一のツリーを生成できるように、生成された正確なツリーについて説明します。このファイルはソースリポジトリ にコミットされることを意図しており、さまざまな目的に役立ちます。
チームメイト、配置、および継続的統合によって、まったく同じ依存関係がインストールされることが保証されるように、依存関係ツリーの単一の表現を記述します。
ディレクトリ自体をコミットしなくても、ユーザが以前の状態の
node_modulesに「タイムトラベル」できるようにする機能を提供します。読み取り可能なソース管理差分を使用してツリーの変更をより見やすくします。
また、npmが以前にインストールされたパッケージのために繰り返されるメタデータ解決をスキップできるようにすることでインストールプロセスを最適化します。
package-lock.jsonに関する1つの重要な詳細は、それが公開されることができないということです、そしてトップレベルパッケージ以外のどこかで見つけられるなら、それは無視されるでしょう。それはnpm-shrinkwrap.json（5）とフォーマットを共有します。これは本質的に同じファイルですが、公開は可能です。 CLIツールをデプロイするか、プロダクションパッケージを作成するためのパブリケーションプロセスを使用しない限り、これはお勧めできません。
package-lock.jsonとnpm-shrinkwrap.jsonの両方がパッケージのルートに存在する場合、package-lock.jsonは完全に無視されます。
はい、それはチェックインされることを意図しています。私はそれがそれ自身のユニークなコミットを得ることを提案したいです。私達はそれが私達のdiffに多くのノイズを加えることを発見しました。
はい、ベストプラクティスはチェックインすることです
差分を見ると、それが多くのノイズや衝突を引き起こすことに同意します。しかし、利点は以下のとおりです。
- すべてのパッケージの正確に同じバージョンを保証する 。この部分は、さまざまな環境でさまざまな時期に構築する場合に最も重要です。
^1.2.3にpackage.jsonを使用することはできますが、npm installがあなたの開発マシンとビルドサーバ、特にそれらの間接的な依存関係パッケージで同じバージョンを拾うたびにどうやって確実にすることができますか？まあ、package-lock.jsonはそれを確実にするでしょう。 （ロックファイルに基づいてパッケージをインストールするnpm ciの助けを借りて） - インストールプロセスが改善されます。
- これは新しい監査機能
npm audit fixに役立ちます（監査機能はnpmバージョン6から来たと思います）。
私は自分のプロジェクトでこのファイルをコミットしません。ポイントは何ですか ？
- 生成された
- これは、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
これにより、 "Binary file a/package-lock.jsonとb/package-lock.jsonは、パッケージロックファイルが変更されるたびに異なります"と表示されます。これをするときオンラインで見るときdiffからのこれらのファイル（これ以上10k行は変更されていない！）。
はい、あなたはこのファイルをコミットすることができます。 npmの公式文書より ：
package-lock.jsonは、npmがnode_modulesツリーまたはpackage.jsonのいずれかを変更する操作に対して自動的に生成されます。中間の依存関係の更新に関係なく、後続のインストールで同一のツリーを生成できるように、生成された正確なツリーについて説明します。このファイルはソースリポジトリにコミットすることを意図しています[。]
はい、する必要があります。
package-lock.jsonをコミットします。- CIとローカル開発マシンの両方でアプリケーションをビルドする場合は、
npm ciの代わりにnpm installを使用します
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から、まさにそれを得ることができます：既知の動作状態。
過去には、ランダムな依存関係が破壊的な更新を受けたためにビルドが1日失敗するpackage-lock.json/npm-shrinkwrap.json/yarn.lockファイルのないプロジェクトがありました。
これらの問題は、最後の作業バージョンが何であるかを推測する必要があるため、解決が困難です。
新しい依存関係を追加する場合でも、npm install {dependency}を実行します。アップグレードする場合は、npm update {dependency}またはnpm install ${dependendency}@{version}を使用して、変更したpackage-lock.jsonをコミットします。
アップグレードが失敗した場合、最後の動作確認済みpackage-lock.jsonに戻すことができます。
宛先 quote npm doc ：
生成されたパッケージロックをソース管理にコミットすることを強くお勧めします。これにより、チームの他のユーザー、デプロイメント、CI /継続的統合、およびパッケージソースでnpmインストールを実行する他のユーザーがまったく同じ依存関係ツリーを取得できるようになりますあなたが開発していたこと。さらに、これらの変更の差分は人間が読み取れるものであり、npmがnode_modulesに加えた変更を通知するため、推移的な依存関係が更新されたり、引き上げられたりしたかどうかを確認できます。
npm ciとnpm installの違い に関して：
- プロジェクトには、既存のpackage-lock.jsonまたはnpm-shrinkwrap.jsonが必要です。
- パッケージロックの依存関係がpackage.jsonの依存関係と一致しない場合、パッケージロックを更新する代わりに、
npm ciがエラーで終了します。npm ciは一度にプロジェクト全体のみをインストールできます。このコマンドでは個々の依存関係を追加できません。node_modulesが既に存在する場合、npm ciがインストールを開始する前に自動的に削除されます。package.jsonやパッケージロックのいずれにも書き込まれません。インストールは基本的に凍結されます。
注：同様の回答を投稿しました here
私のnpmの使い方は、縮小/非公開のcss/jsを生成し、Djangoアプリケーションによって提供されるページに必要なJavaScriptを生成することです。私のアプリケーションでは、Javascriptがアニメーションを作成するためにページ上で実行され、ときどきajax呼び出しを実行したり、VUEフレームワーク内で作業したり、CSSで作業したりします。 package-lock.jsonがpackage.json内の内容をオーバーライド制御する場合は、このファイルに1つのバージョンがあることが必要な場合があります。私の経験では、npm installによってインストールされたものに影響を与えないか、そうであったとしても、私が知る限りではデプロイするアプリケーションに悪影響を与えていません。私は伝統的にシンクライアントであるmongodbや他のそのようなアプリケーションを使用しません。
Npm installはこのファイルを生成し、npm installはアプリを実行する各サーバーのデプロイプロセスの一部であるため、私はrepoからpackage-lock.jsonを削除します。 nodeとnpmのバージョン管理は各サーバー上で手動で行われますが、私はそれらが同じであることに注意します。
npm installがサーバー上で実行されると、package-lock.jsonが変更されます。サーバー上のリポジトリによって記録されたファイルに変更がある場合は、次回のデプロイでOriginから新しい変更を取得することができます。 pullするとpackage-lock.jsonに加えられた変更が上書きされるため、デプロイできません。
Package-lock.jsonに含まれているものが反映されていない場合は、コマンドを発行するたびにnpmが文句を言うので、ローカルに生成されたpackage-lock.jsonをリポジトリにあるもので上書きすることはできません（ハードOriginマスターのリセット）。 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をインストールしたり、npmをjs/cssのビルドに適用したりすると、build-lock.jsonを削除しても苦情はありません。
jason@localhost:introcart_wagtail$ rm package-lock.json
jason@localhost:introcart_wagtail$ npm run dev
> [email protected] dev /home/jason/webapps/introcart_devtools/introcart_wagtail
> NODE_ENV=development webpack --progress --colors --watch --mode=development
10% building 0/1 modules 1 active ...
package-lock.jsonをグローバルに無効にする
端末に次のように入力します。
npm config set package-lock false
これは本当に魔法のように私のために働く
はい、それはpackage-lock.jsonをコミットすることが標準的なやり方です
Package-lock.jsonをコミットする主な理由は、プロジェクト内の全員が同じパッケージバージョン上にあることです。
長所： -
プロジェクト内の全員が同じパッケージバージョンになります。
npmインストール
厳密なバージョン管理に従い、サードパーティパッケージの下位互換性のない変更からあなた自身を救うために自動的にメジャーバージョンへの更新を許可しないならば、package-lockをコミットすることは大いに役立ちます。
短所： -
- それはあなたがプルリクエストを醜く見えるようにすることができます。