[解決済み] なぜ "npm install" は package-lock.json を書き換えてしまうのですか？

質問

にアップグレードしたばかりです。 npm@5 . 現在、私は パッケージロック.json のすべてを含むファイルです。 パッケージ.json . を実行したとき、私はそれを期待します。 npm install に何をインストールすべきかを決定するために、依存関係のバージョンがロックファイルから引き出されます。 ノードモジュール ディレクトリに格納されます。 不思議なのは、実際に私の パッケージロック.json ファイルを作成します。

例えば、ロックファイルにはtypescriptが指定されており、バージョン 2.1.6 . そして npm install コマンドを実行すると、バージョンが 2.4.1 . これではロックファイルの意味がないように思えます。

何が足りないのでしょうか？ どうすればnpmがロックファイルを実際に尊重するようになるのでしょうか？

解決方法は？

アップデート3: 他の回答でも指摘されているように npm ci コマンドは、CIコンテキストで高速かつ再現性のあるビルドを実現するための追加手段として、npm 5.7.0から導入されました。詳細は ドキュメント と npmブログ をご覧ください。

アップデート2 ドキュメントを更新し、明確にするための課題は GitHub issue #18103 .

アップデート1: 以下に説明されている動作は npm 5.4.2 で修正されました: 現在意図されている動作は以下の通りです。 GitHub issue #17979 .

オリジナルの回答です。 の挙動は package-lock.json で変更されました。 npm 5.1.0 で説明したように 課題番号16866 . あなたが観察した動作は、バージョン5.1.0の時点でnpmが意図したものであることが明らかです。

ということは package.json をオーバーライドすることができます。 package-lock.json の依存関係に新しいバージョンが見つかった場合は、常に package.json . 依存関係を効果的に固定したい場合は、バージョンをプレフィックスなしで指定する必要があります。 1.2.0 ではなく ~1.2.0 または ^1.2.0 . という組み合わせになります。 package.json と package-lock.json を使えば、再現性のあるビルドができます。はっきり言って package-lock.json だけでは、もはやルートレベルの依存関係をロックすることはできません!

この設計上の決定が良かったかどうかは議論の余地がありますが、この混乱から生じた議論がGitHubの 課題番号17979 . (私の目には、これは疑問のある決定であり、少なくとも名前 lock はもう通用しない)

もうひとつ余談ですが、npmjs.org ではなく GitHub から直接パッケージを取得する場合など、immutable パッケージをサポートしないレジストリに対する制限もあります。以下を参照してください。 パッケージロックに関するこの文書 をご覧ください。