「npm install」がpackage-lock.jsonを書き換えるのはなぜですか？

最近npm @ 5にアップグレードしました。これで、package.jsonのすべてを含むpackage-lock.jsonファイルができました。私が実行すると、依存関係バージョンがロックファイルからプルされ、node_modulesディレクトリに何をインストールする必要があるかが決定されると思います。奇妙なのは、それが実際に私のpackage-lock.jsonファイルを変更して書き直してしまうことです。npm install

たとえば、ロックファイルにはtypescriptがバージョン2.1.6に指定されていました。その後、npm installコマンドの後、バージョンは2.4.1に変更されました。これは、ロックファイルの目的全体を無効にするようです。

何が欠けていますか？npmで実際にロックファイルを尊重するにはどうすればよいですか？

更新3：他の回答でも指摘されているように、このnpm ciコマンドは、CIコンテキストで高速かつ再現可能なビルドを実現する追加の方法としてnpm 5.7.0で導入されました。詳細については、ドキュメントとnpmブログを参照してください。

更新2：ドキュメントを更新および明確化するための問題は、GitHubの問題＃18103です。

更新1：以下で説明されている動作がnpm 5.4.2で修正されました。現在意図されている動作は、GitHubの問題＃17979で概説されています。

元の回答：問題＃16866で説明されているようにpackage-lock.json、npm 5.1.0での動作が変更されました。観察される動作は、バージョン5.1.0の時点でnpmによって意図されているようです。

つまり、で依存関係の新しいバージョンが見つかった場合は常にpackage.jsonオーバーライドできます。依存関係を効果的に固定するには、プレフィックスなしでバージョンを指定する必要があります。たとえば、またはの代わりにバージョンを記述する必要があります。次に、との組み合わせにより、再現可能なビルドが生成されます。明確にするために：単独ではルートレベルの依存関係がロックされなくなりました！package-lock.jsonpackage.json1.2.0~1.2.0^1.2.0package.jsonpackage-lock.jsonpackage-lock.json

この設計上の決定が良かったかどうかは議論の余地がありますが、問題＃17979の GitHubでこの混乱の結果として進行中の議論があります。（私の目では、それは疑わしい決定です;少なくとも名前lockはもはや真実ではありません。）

もう1つの注意事項：npmjs.orgではなくGitHubから直接パッケージをプルする場合など、不変のパッケージをサポートしないレジストリーにも制限があります。詳細については、このパッケージロックのドキュメントを参照してください。

私は、NPMの新バージョンが存在することを発見しました5.7.1の新しいコマンドを使用してnpm ciからインストールします、package-lock.jsonのみ

新しいnpm ciコマンドは、ロックファイルからのみインストールします。package.jsonとロックファイルが同期していない場合、エラーが報告されます。

これは、node_modulesを破棄し、最初から再作成することで機能します。

あなたがあなたのロックファイルにあるものだけを取得することを保証するだけでなく、node_modulesで始めないときは、npm installよりもはるかに高速です（2x-10x！）。

名前からわかるように、継続的な統合環境にとって大きな恩恵となることを期待しています。また、Gitタグから本番環境にデプロイするユーザーには、大きな利益が期待できます。

新しく導入された

npm ci

npm ciは、大規模なチームに最大のメリットを約束します。パッケージロックに「サインオフ」する機能を開発者に与えることで、大規模なチーム全体でのより効率的なコラボレーションが促進され、ロックファイルにあるものを正確にインストールできる機能により、月に数百時間ではないにしても数十時間の開発者を節約でき、チームを解放できます。素晴らしいものを作り、出荷するためにより多くの時間を費やすため。

npm ciより高速で信頼性の高いビルドのための紹介

簡潔な答え：

• npm install package.jsonの要件を満たしている場合にのみ、package-lock.jsonを受け入れます。
• これらの要件を満たさない場合、パッケージが更新され、package-lockが上書きされます。
• ビルドに失敗した場合は、パッケージロックが発生したときに書き換えるのではなく、を使用してくださいnpm ci。

これは説明する可能性のあるシナリオです（NPM 6.3.0で検証済み）

次のように、package.jsonで依存関係を宣言します。

"depA": "^1.0.0"

次に、次のようにしnpm installてpackage-lock.jsonを生成します。

"depA": "1.0.0"

数日後、 "depA"の新しいマイナーバージョンがリリースされます（ "1.1.0"など）。次のことが当てはまります。

npm ci       # respects only package-lock.json and installs 1.0.0

npm install  # also, respects the package-lock version and keeps 1.0.0 installed 
             # (i.e. when package-lock.json exists, it overrules package.json)

次に、package.jsonを手動で次のように更新します。

"depA": "^1.1.0"

次に、再実行します。

npm ci      # will try to honor package-lock which says 1.0.0
            # but that does not satisfy package.json requirement of "^1.1.0" 
            # so it would throw an error 

npm install # installs "1.1.0" (as required by the updated package.json)
            # also rewrites package-lock.json version to "1.1.0"
            # (i.e. when package.json is modified, it overrules the package-lock.json)

のnpm ci代わりにコマンドを使用しnpm installます。

「ci」は「継続的統合」の略です。

寛大なpackage.jsonファイルの依存関係ではなく、package-lock.jsonファイルに基づいてプロジェクトの依存関係をインストールします。

それはあなたのチームメイトと同一のビルドを生成し、それもはるかに高速です。

詳細については、次のブログ投稿をご覧ください。https： //blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable

将来的には、あなたが使用することができます--from-lock-fileインストールする（または類似の）フラグのみからpackage-lock.json、それを修正することなく。

これは、再現可能なビルドが重要なCIなどの環境で役立ちます。

機能の追跡については、https：//github.com/npm/npm/issues/18286を参照してください。

この問題はnpm v5.4.2で修正されたようです

https://github.com/npm/npm/issues/17979

（スレッドの最後のコメントまでスクロールします）

更新

5.6.0で実際に修正されました。5.4.2にクロスプラットフォームのバグがあり、それが原因で問題が引き続き発生していました。

https://github.com/npm/npm/issues/18712

アップデート2

ここで私の答えを参照してください：https : //stackoverflow.com/a/53680257/1611058

npm ci 既存のプロジェクトを今すぐインストールするときに使用する必要があるコマンドです。

あなたはおそらく次のようなものを持っています：

"typescript":"~2.1.6"

あなたにpackage.jsonそのあなたのケースであることに、最新のマイナーバージョンへの更新をNPM2.4.1

編集：OPからの質問

しかし、「npm install」がロックファイルを変更する理由は説明されていません。ロックファイルは再現可能なビルドを作成するためのものではありませんか？その場合、semverの値に関係なく、同じ2.1.6バージョンを使用する必要があります。

回答：

これは、完全な依存関係ツリーをロックすることを目的としています。まあ言ってみればtypescript v2.4.1必要ですwidget ~v1.0.0。npmをインストールすると、インストールされますwidget v1.0.0。後で仲間の開発者（またはCIビルド）がnpmインストールを実行して取得しますtypescript v2.4.1が、widgetに更新されましたwidget v1.0.1。これで、ノードモジュールが同期しなくなりました。これがpackage-lock.json妨げるものです。

またはより一般的には：

例として、

パッケージA：

{"名前"： "A"、 "バージョン"： "0.1.0"、 "依存関係"：{"B"： "<0.1.0"}}

パッケージB：

{"名前"： "B"、 "バージョン"： "0.0.1"、 "依存関係"：{"C"： "<0.1.0"}}

そしてパッケージC：

{「名前」：「C」、「バージョン」：「0.0.1」}

これらがレジストリで使用可能なA、B、およびCの唯一のバージョンである場合、通常のnpmインストールAがインストールされます。

A@0.1.0-B@0.0.1-C@0.0.1

ただし、B @ 0.0.2が公開されている場合は、新しいnpmインストールAがインストールされます。

A@0.1.0-B@0.0.2-C@0.0.1は、新しいバージョンがBの依存関係を変更しなかったと想定しています。もちろん、新しいバージョンのBには、新しいバージョンのCと任意の数の新しい依存関係を含めることができます。そのような変更が望ましくない場合、Aの作成者はB@0.0.1への依存関係を指定できます。ただし、Aの作成者とBの作成者が同じ人物ではない場合、Aの作成者は、Bがまったく変更されていない場合に、新しく公開されたバージョンのCを取り入れたくないと言うことはできません。

OP質問2：では、私が正しく理解しているかどうかを確認しましょう。あなたが言っているのは、ロックファイルが二次依存関係のバージョンを指定しているにもかかわらず、package.jsonのあいまい一致に依存して、トップレベルの依存関係を決定しているということです。それは正確ですか？

回答：いいえ。package-lockは、で説明されているルートパッケージを含むパッケージツリー全体をロックしますpackage.json。場合typescriptにロックされている2.4.1あなたにpackage-lock.jsonそれが変更されるまで、それはそのように残っている必要があります。そして明日typescriptリリース版としましょう2.4.2。私がブランチをチェックアウトして実行するとnpm install、npmはロックファイルを尊重してインストールし2.4.1ます。

詳細package-lock.json：

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

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

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

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

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

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

https://docs.npmjs.com/files/package-lock.json

おそらくあなたはこのようなものを使うべきです

npm ci

使用する代わりに npm install パッケージのバージョンを変更したくない場合する。

公式ドキュメントによると、npm installとnpm ciプロジェクトに必要な依存関係をインストールします。

主な違いは、リファレンスとしてnpm installパッケージをインストールすることpackge.jsonです。の場合、参照としてnpm ciパッケージをインストールしpackage-lock.json、正確なパッケージがインストールされるたびに確認します。

彼らのgithubページにこれに関する未解決の問題があります：https：//github.com/npm/npm/issues/18712

この問題は、開発者が異なるオペレーティングシステムを使用している場合に最も深刻です。

編集：「ロック」という名前はトリッキーなもので、そのNPMはヤーンに追いつけようとします。ロックされたファイルではありません。package.jsonユーザーが修正したファイルで、「インストール」するとnode_modulesフォルダツリーが生成され、そのツリーがに書き込まれpackage-lock.jsonます。つまり、その逆です-依存関係バージョンはpackage.jsonいつものようにプルされ、package-lock.json呼び出される必要がありますpackage-tree.json

（非常に多くの反対投票の後、これにより私の答えがより明確になったことを願っています）

単純な答え：package.json通常どおり依存関係を保持しますが、これpackage-lock.jsonは「正確で、より重要なことには再現可能なnode_modulesツリー」です（npm docs自体から取得）。

トリッキーな名前について言えば、そのNPMはYarnに追いつけようとしています。