これは、ci / cleaninstallが意図していることではありません。 現在の動作は正しいです。 使用したいのはnpm shrinkwrapです。

node_modules _folder_は削除されないように更新を追加しましたが、その_contents_は削除しませんとおり）。 npm ciコマンドの目的は、クリーンな状態から開始するためにすべてを削除することです。 古いnode_modulesを保持したい場合、必要なのはnpm iです。

返信ありがとうございます！ 私の返事が遅れて申し訳ありません。 npm shrinkwrapを見てきましたが、これは継続的インテグレーションのためにビルドサーバーで実行することを目的としていますか？ このコマンドを実行すると、 package-lock.json名前がnpm-shrinkwrap.jsonが、CI中に何を実行する必要がありますか？ 増分更新を行うにはnpm installだけですか？ または、 npm ciを実行する必要がありますが、すべてのパッケージが再度削除されます:-(私が探しているのは、増分更新を実行するが、 package-lock.jsonにあるものを正確にインストールするコマンドです。

@claudiahdz; 私の理解では、CI中にnpm installを実行すると、 package-lock.jsonが更新されます。つまり、数週間後に同じビルドを実行すると、異なるパッケージがインストールされる可能性があります。 それは間違っていますか？

Ps私はnpm ciは継続的インテグレーションの略だと思いました

ここで参照されているように： https ：

Dockerコンテナ内でnpm ciを使用していて（継続的インテグレーションでは非常に一般的です）、 node_modulesバインドマウントがある場合、現在の動作は問題があります。

次のエラーが発生します。

webpack_1   | npm ERR! path /var/www/project/docker-config/webpack-dev-devmode/node_modules
webpack_1   | npm ERR! code EBUSY
webpack_1   | npm ERR! errno -16
webpack_1   | npm ERR! syscall rmdir
webpack_1   | npm ERR! EBUSY: resource busy or locked, rmdir '/var/www/project/docker-config/webpack-dev-devmode/node_modules'

その結果、Dockerコンテナが中止されます。

--no-deleteフラグがあるか、 npm ciがnode_modulesの_contents_を削除できても、ディレクトリ自体は削除できないと便利です。

ci =クリーンインストール

これは予想されます。 ロックファイルで通常のnpm iを使用してみませんか？

--no-deleteフラグがあるか、npm ciがnode_modulesのコンテンツを削除できても、ディレクトリ自体は削除できないと便利です。

rm -rf node_modules/* && npm i

ci =クリーンインストール

これは予想されます。 通常のnpmiをロックファイルで使用してみませんか？

...理由： https ：

またはあなたはあなたがあなたの依存関係のクリーンインストールをやっているようにしたいどのような状況-このコマンドは、このようなテスト・プラットフォーム、継続的インテグレーション、および配備などの自動化環境で使用するためのものだ除いて、インストールNPMに似ています。 特定のユーザー指向の機能をスキップすることで、通常のnpmインストール大幅に高速化できます。 また、通常のインストールよりも厳密であるため、ほとんどのnpmユーザーの段階的にインストールされるローカル環境によって引き起こされるエラーや不整合を見つけるのに

より高速なインストールとクリーンスレートアプローチにより、これは上記のようなCI環境に最適です。

rm -rf node_modules / * && npm i

これは私が今していることですが、 npm ciを使用したいという願望については上記を参照してください

npm ciがdir自体ではなくnode_modulesの内容を削除するようにする構成フラグを要求するRFCを提出することは私には合理的であるように思われます。 これは、 node_modulesディレクトリを選択的に無視するようにDropboxを設定したという点でも問題ですが、削除すると、その選択設定はなくなり、次回はnode_modules作成され、同期されます。

npm ciがdir自体ではなくnode_modulesの_contents_を削除するようにする構成フラグを要求するRFCを提出することは私には合理的であるように思われます。 これは、 node_modulesディレクトリを選択的に無視するようにDropboxを設定したという点でも問題ですが、削除すると、その選択設定はなくなり、次回はnode_modules作成され、同期されます。

これは、npmがディレクトリを無視するファイルを作成できるようにするための別の問題（OSXスポットライトなどの場合）についても説明されていませんか？ この機能を必要としている人もいたと思います。

ci =クリーンインストール

これは予想されます。 ロックファイルで通常のnpm iを使用してみませんか？

npm iは素晴らしいでしょうが、それがロックファイルを変更しない場合に限ります。 package-lock.jsonがnpm i間に更新されるのを見ましたか、それとも起こらないはずですか？

私はこの機能をサポートしています。 前述のように、 npm iはpackage-lock.jsonを変更します。 フラグが理想的な解決策になります。

同じように、旗は素晴らしいでしょう

私はこの機能をサポートしています。 前述のように、 npm iはpackage-lock.jsonを変更します。 フラグが理想的な解決策になります。

では、 npm iフラグを追加してみませんか？ 私の意味では、これはci = clean installにはあまり意味がないからです。

「クリーンインストール」のどの部分が、親node_modules/ディレクトリをそのまま維持することと互換性がありませんか（実際のコンテンツのクリーンインストールを実行している間）？

この場合、CIは継続的インテグレーションの略ではないことを理解しています。 ただし、ドキュメントに記載されているように、クリーンインストールは継続的インテグレーション環境で非常に役立つことがよくあります。

このコマンドはnpm-installに似ていますが、テストプラットフォーム、継続的インテグレーション、デプロイメントなどの自動化された環境、または依存関係のクリーンインストールを確実に実行する必要がある状況で使用することを目的としています。 特定のユーザー指向の機能をスキップすることで、通常のnpmインストールよりも大幅に高速化できます。 また、通常のインストールよりも厳密であるため、ほとんどのnpmユーザーの段階的にインストールされるローカル環境によって引き起こされるエラーや不整合を見つけるのに役立ちます。

npm ciは特に自動化された環境で使用することを意味し、多くの場合、これはDockerベースのセットアップを意味します。

node_module/ディレクトリを削除する動作は、このスレッドで言及されている理由により、Dockerベースのセットアップでは厄介です。

そのため、このコマンドを本来の目的と環境に役立つようにするオプションを求めています。

私はこの機能をサポートしています。 前述のように、 npm iはpackage-lock.jsonを変更します。 フラグが理想的な解決策になります。

では、 npm iフラグを追加してみませんか？ 私の意味では、これはci = clean installにはあまり意味がないからです。

私はこの質問をしなければなりませんnpm installとnpm ci間の他の違いはそうでない場合、なぜ両方のオプションがnpm install利用できないのですか？おそらくciニーズnpm install --no-update-package-lock --clean-node-modulesようなエイリアスになります

node_module/ディレクトリを削除する動作は、このスレッドで言及されている理由により、Dockerベースのセットアップでは厄介です。

私の意見では、これはイメージが構築されたときに一度だけ発生するはずです。 その後、開発中にnpm iを使用する必要があります。

たぶんciはnpm install --no-update-package-lock --clean-node-modulesようなエイリアスになる必要があります

個人的には、通常のnpm iコマンドの追加フラグの方が理にかなっています。

私はそれに無関心であり、正直なところ、jsランドを持つn00bが多すぎて、 ciでなければならないという具体的な議論ができません。私が知っているのは、 package-lock.jsonを更新してはならないということだけです。 node_modules削除しないでください

npm ciはロックファイルを更新せず、ロックファイルからインストールします。 これは、クリーンインストールを実行するために導入されました。これは、以前はrm -rf node_modulesを実行して、 npm i再度実行するようにアドバイスされていたためです。 そして、afaikの人々は、ロックファイルを変更せず、そこからインストールすることを望んでいました。

それでnpm ciが生まれました。 また、インストールされているパッケージとツリーのリストなど、いくつかの項目をスキップします。

https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliableを参照して

特定のユースケースをカバーしています。

他のユースケースでは、新しいフラグをnpm i追加する必要があります。これを使用して、 npm ciをエミュレートすることもできます。これは、 npm ciフラグよりも柔軟で、優れたソリューションです。現在のユースケースimho。 ここでユーザーが要求するものは、 yarn install --frozen-lockfileまたはyarn --frozen-lockfile少し似ています。

それ以外の場合、フラグはnpm ci 、 npm iなどに分散されるため、少し難しくなります（ドキュメント、コードなど）。 少なくともこれは私が思うことです。 それをnpm i入れてみましょう。その動作を構成するためのより強力で柔軟な方法があります。

他のユースケースでは、npm iwithに新しいフラグを追加する必要があります。これは、現在のユースケースimhoのみをカバーする必要があるnpmciのフラグよりも柔軟で優れたソリューションであるnpmciをエミュレートすることもできます。 ここでユーザーが要求するのは、yarn install--frozen-lockfileまたはyarn--frozen-lockfileに少し似ています。

この機能がnpm iに追加されたら、とてもうれしいです。 元の投稿を更新する必要がありますか？

npm ciはロックファイルを更新せず、ロックファイルからインストールします。 これは、クリーンインストールを実行するために導入されました。これは、以前はrm -rf node_modulesを実行して、 npm i再度実行するようにアドバイスされていたためです。 そして、afaikの人々は、ロックファイルを変更せず、そこからインストールすることを望んでいました。

それでnpm ciが生まれました。 また、インストールされているパッケージとツリーのリストなど、いくつかの項目をスキップします。

https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliableを参照して

特定のユースケースをカバーしています。

他のユースケースでは、新しいフラグをnpm i追加する必要があります。これを使用して、 npm ciをエミュレートすることもできます。これは、 npm ciフラグよりも柔軟で、優れたソリューションです。現在のユースケースimho。 ここでユーザーが要求するものは、 yarn install --frozen-lockfileまたはyarn --frozen-lockfile少し似ています。

rm -rf node_modules/* 「クリーニング」の対象にならないのはどうしてですか？ ここで尋ねられる機能は、npmciに存在する機能と非常によく似ています。 私の意見では、npm ciにフラグを追加して、npmciの動作全体をnpmiにインポートする代わりに、 rm -rf node_modulesではなくrm -rf node_modules/*使用する方が理にかなっています。

ところで、この問題はもっと注目されるべきであり、メンテナはそれについて意見や計画を表明する必要があります。dockerの使用は基本的に、npm ciの主なユースケースの1つであるCI（継続的インテグレーション）で常に使用されます。

このリポジトリの問題ではなく、この変更のRFCを開いてください。

混乱を避けるために、この問題の名前を「npmCIのnode_modulesdirを削除する代わりに空にする」に変更します。

この問題の私の意図は、 node_modulesフォルダーを削除することではなく、その内容のみを削除することでした。 常にnode_modulesの内容を保持することpackage-lock.jsonと同期していることを確認してください。 したがって、 package-lock.json準拠する増分更新。

私は間違っているかもしれませんが、ここには2つの問題があると感じています。 たぶん誰かがフォルダを完全に削除する代わりにnode_modulesの内容だけを削除することについて別の問題やRFCを始めることができますか？ それとも私は何かが足りないのですか？

@Zenuka npm CIが高速で存在する理由は、既存のnode_modules dirを無視するため、変更される可能性はほとんどありません。

私たちのユースケースでは、 nodes_modulesフォルダーが最新であるかどうかを確認するだけの方が速いと思います。 そうでない場合は、更新する必要のあるパッケージのみを更新します（ npm iように）ビルドエージェントとして実行されている専用VMがあるため、ビルドを実行し、 nodes_modulesフォルダーとそのすべてのコンテンツを保持しますすべてを削除して再インストールするよりも高速である必要があります。 ビルドを実行し、コードの変更をテストするのは、 package.jsonまたはpackage-lock.jsonへの変更よりもはるかに多いです。

私たちのユースケースでは、 nodes_modulesフォルダーが最新であるかどうかを確認するだけの方が速いと思います。

さて、これ（パッケージツリーの計算）が最も時間がかかるものです。 このチェックにより、 npm ci非常に遅くなります。

ビルドを実行し、 nodes_modulesフォルダーとそのすべての内容を保持する方が、すべてを削除して再インストールするよりも高速である必要があります。

なぜおそらくない、それはだnpm ci何をどのスキップ紹介されましたnpm i （パッケージツリーを確認してください）んが。

@Zenuka npm installすでにあなたが欲しいものを行うための最速の方法です。 npm ci目的は1つだけです。それは、node_modulesを削除して差分を計算する必要がないようにすることで、より高速に実行することです。

おそらくそうではないので、npm iが行うことをスキップするnpmciが導入されました（パッケージツリーを確認してください）。

私はこれを自分のマシンでのみテストしましたが（もちろんこれは良い方法ではありません）、最新のnode_modulesフォルダーでnpm installを実行すると10秒以内に終了します。 npm ciは数分かかります。 別の結果を期待しますか？

私はnpm installロックファイルをフリーズするフラグを追加するというあなたの提案のファンです。

package-lock.jsonが実際に存在することを確認することは、Windows上でも非常に高速です。 https://github.com/fuzzykiller/verify-node-modulesを参照して

node_modules他に何も存在しないことを確認するには、確かに少し時間がかかりますが、おそらく1秒未満です。

これに基づいて、 npm ci増分バージョンを簡単に作成できます。 結局のところ、ツリーはすでに計算され、 package-lock.jsonに保存されています。

また、基本的にnpm ciが存在する唯一の理由は、 package-lock.jsonものをインストールすることです。 npm installように、サプライズアップグレードをこっそりと行うことはありません。

ちょうど私の2セント、私は古いタグの展開にもうんざりしていたので、私は個人的にインフラをnpm ci切り替えましたnpm iはロックファイルに固執しませんでした... npm ciレベルでフラグを追加するという大きな問題（私が得たもの..そのclean installは、言われたとおりに動作します）、 npm i REALLLLLYLYYはこのフラグを必要とします。 しかし、私はこれを調査したことを覚えています。 npm iには、2年以上前の（そしてまだ開いている）問題スレッドがあり、npmチームは人々がnpm ci使用することを提案しました笑...これ人々が過去にnpmをあきらめて、ただ糸に行ったのはちょっと理由です。

再びちょうど別の開発者の視点

モジュールを保持する可能性を追加することに投票しました：heavy_plus_sign:。

ここで+ 1- @ phyzicalと@fuzzykillerが言ったように、 npm installとnpm ci間にnode_modulesを保持する「スイートスポット」はありませんが、それでもpackage-lock.jsonを尊重し、より高速に実行されます。
できるだけ速く実行してください-node_modulesにすでに存在するpackage-lockからの依存関係を探してから、不足している他のすべてをインストールしてください。アップグレードも削除もありません。

個人的には、これがどちらであるか（ installまたはci ）は関係ありませんが、 npm installように聞こえますが、すべてのフラグとnpm ciは別のコマンドである必要はありません。

npm ciが元々、この問題が提起しているのと同じ問題の解決策として宣伝されていた

多くの人がnpm installに求めていた元々の動作は、 package-lock.jsonではなくpackage.json 。 その動作をオンにするために、 npm installにフラグが必要npm ci 。理由は、次のとおりです。

package.jsonは、プロジェクトに必要な依存関係を記述します。 現在のロックファイルがそれらを満たすことができない場合、ロックファイルは譲歩する必要があります。 ロックファイルの目的は、package.jsonを廃止することではなく、異なるマシン間で繰り返し可能なインストールを作成することです。

だから、結構です。 npm installはそのオプションに適した場所ではなく、 npm ciは適切な場所です。 npm ci除いて、元の問題の有用な解決策にならないようにする追加の動作（ node_modulesフォルダーをクリアする）が追加されます。 そして、現在npm ciフラグを立てることができない理由は、次の理由によるものです。

ci =クリーンインストール

これは予想されます。 通常のnpmiをロックファイルで使用してみませんか？

これは...大丈夫です。 フラグがどこに追加されるかはあまり気にしません。 私は、インターフェースの背後にある根本的な哲学には何の利害関係もありません。 しかし、フラグをどこかに追加し

一体、人々が完全に別の3番目のコマンドを望んでいたとしても、私は異議を唱えませんでした。 私が気にかけている唯一のことは、通常のインストールでpackage-lock.jsonを尊重することについてのこの会話が始まってから、3年経っても、当初求めていた動作を取得する方法がまだないということです。

私の職場では、パッケージのマイナーバージョンとバグ修正バージョンのアップデートによるバグが見られました。 私たちは本当に、意図的なパッケージのアップグレード中にこれらのバグを探したいだけです。開発環境が本番環境とは異なるパッケージバージョンを使用することは望ましくありません。 一貫性は非常に重要です。 誰もがそれを呼び出すために望んでいるか、誰がそれを置くために望んでいるところはどこでも、我々はを通じても座ることを求めないことをロックファイルからパッケージを取得するための高速な方法たいものは何でもnode-gypたびに、我々既にインストールされたモジュール用のビルドをコマンドを実行します。

これが私が完璧な世界で機能させたい方法です：

• npm install -今日と同じ動作
• npm install --from-lockfile -ロックファイルからインストールします（ ciように）
• npm install --clean - npm installと同じ動作ですが、 node_modulesコンテンツを削除します
• npm ci - npm install --from-lockfile --cleanエイリアス

@jdussouillezこれはまさに起こるべきことです。 非常によく言いました！ このソリューションが導入されるのを楽しみにしています。

CIパイプラインの速度と一貫性のどちらかを決定する必要があるこの問題に遭遇することは、一貫して苛立たしいことです。 過去2か月だけで、さまざまな理由で3〜4回遭遇しました。

この機能は、Azureパイプラインやその他のクラウドアーキテクチャに最適です。

https://docs.microsoft.com/en-us/azure/devops/pipelines/release/caching?view=azure-devops#tip

npm ciはnode_modulesフォルダーを削除して、一貫性のある繰り返し可能なモジュールのセットが使用されるようにするため、npmciを呼び出すときにnode_modulesをキャッシュしないようにする必要があります。

締めくくり： @claudiahdzが述べたように、 npm ciがnode_nodulesフォルダー自体を削除せず、その内容のみを削除するというこの動作の修正を出荷しました（https://github.com/npmを参照）。 /libcipm/blob/latest/CHANGELOG.md#407-2019-10-09）。 これは7月21日に[email protected]出荷され（https://github.com/npm/cli/blob/v6/CHANGELOG.md#6147-2020-07-21を参照）、 npm@7同じ経験。

npm ciまたはその他のコマンドで別の問題が発生した場合は、問題テンプレートの1つを使用してバグを報告してください： //github.com/npm/cli/issues/new/choose

サイドノート...

@jdussouillezはフィードバックに感謝します。 ロックファイルから直接インストールするという点では、今日はフラグ--package-lock-only （例： npm install --package-lock-only ）を使用してインストールできます。 --cleanフラグをinstallに追加するという点では、これがあまり価値をもたらすとは思わないが、間違っている可能性がある。 あなたがそれについて強く感じているなら、 https：//github.com/npm/rfcsでRFCを提出してもらいたいです

ほぼ1年前に@claudiahdzが行ったコメントは、 npm ci動作が、フォルダ自体ではなく、 node_modulesコンテンツを削除することを確認することに関連しているようです。 これは（たとえば）Dockerコンテナーにマウントするときに便利ですが、それでも最終結果は変わりません- npm ciはすべての依存関係を最初からダウンロードします。

npm install --package-lock-onlyを使用すると、元の問題とは正反対のことが行われるようです（正しく理解している場合）。 package-lock.jsonファイルのみが更新され、依存関係はダウンロードされません。

元の問題から私が理解しているのは、 node_modulesフォルダーの現在の状態とpackage-lock.jsonファイルを取得し、 node_modulesを取得するために必要なパッケージのみをダウンロードするオプションが必要なことです。 package-lock.jsonに一致するnode_modulesバージョン。 したがって、毎回すべてをダウンロードするよりもはるかに高速で、最終的に同じ最終結果が得られます。

それはnpm installすでに常に行っていることではありませんか？

それはnpm installすでに常に行っていることではありませんか？

私の知る限り -
npm installは、 package.jsonファイル（ package-lock.json無視）に従ってすべての依存関係を解決し、現在node_modulesフォルダーにあるものと比較して、要件に一致するためにダウンロードする必要がある依存関係。 また、それに応じてpackage-lock.jsonも更新されます。

それは間違いなくロックファイルを無視しません-それはnpm ciが考慮しない既存のツリーを考慮に入れるだけです。

あなたは正しいです、ごめんなさい。
私は間違って覚えていました（多分それは過去の行動でしたか？）。 単純なdepツリーでいくつかのテストを行ったところ、 package-lock.jsonファイルが存在する場合、 npm iは指定されたバージョンを正確にインストールし、何も変更しません。 これは私が探していた行動だったので、満足しています。 👍
クローズされた問題に投稿して申し訳ありません。

私の最初の要求は確かにATGardnerが説明するものでした：

元の問題から私が理解しているのは、 node_modulesフォルダーの現在の状態とpackage-lock.jsonファイルを取得し、 node_modulesを取得するために必要なパッケージのみをダウンロードするオプションが必要なことです。 package-lock.jsonに一致するnode_modulesバージョン。 したがって、毎回すべてをダウンロードするよりもはるかに高速で、最終的に同じ最終結果が得られます。

npm install私の経験では、 package-lock.jsonファイルが更新されることがあります。 今朝、しばらく更新していなかったリポジトリを使用してこれを再度テストし、 git pullとnpm i 。 今回は実際にはバージョンを更新せず、いくつかの依存関係と追加のパッケージを追加しただけです。

残念ながら、これはプライベートリポジトリですが、再現可能なパブリックリポジトリとして他の誰かがいる可能性がありますか？ 複数のコミットがあり、それらを切り替えると、 npm installがpackage-lock.jsonを更新しますか？

package.json更新するときにpackage-lock.jsonコミットしないと、ユーザーエラーが発生する可能性があることはわかっていますが、同僚はpackage-lock.jsonも更新する必要があることを知っています。 これを調べます。

npm iにpackage-lock.jsonファイルを変更させる簡単な例を取得できませんでした。 しかし、私はそれをもう少し試してみます。

npm i常にpackage-lock.jsonで指定されたものとまったく同じバージョンをダウンロードすることになり、現在のnode_modulesから可能な限り多くを保持する場合、なぜnpm ciを実行する必要があるのでしょうか。

https://docs.npmjs.com/cli/v6/commands/npm-ci#descriptionを参照して

これがこの議論の場ではなかったことを改めてお詫び申し上げます。 他にもっと好ましい場所はありますか？

まだわかりません。 状態ならばnode_modules実行した後にnpm i正確に一致したpackage-lock.json 、との状態node_modules実行した後にnpm ciまったく同じを持っています最終結果-ほとんどすべてのシナリオで、構築しているコンピューターのフォルダーにすでにいくつかの/ほとんどの依存関係があると仮定すると、 npm i方が速くなりませんか？ ローカルにすでに存在するものをダウンロードせず、必要なバージョンと一致します。

すべてを最初から削除してダウンロードするのはなぜですか？

いいえ、 npm ciは、deptreeを再度チェックしないため、さらに高速です。一部のコンソール出力は実行されません。

すべてを最初から削除してダウンロードするのはなぜですか？

問題を防ぐために、 ciは展開などの特定の環境向けです。
ドキュメントにはすでに違いが記載されていると思います。

特定のユーザー指向の機能をスキップすることで、通常のnpmインストールよりも大幅に高速化できます。 また、通常のインストールよりも厳密であるため、ほとんどのnpmユーザーの段階的にインストールされるローカル環境によって引き起こされるエラーや不整合を見つけるのに役立ちます。

https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliableも参照して

npm ciはさらに高速です。

したがって、 npm iを使用する場合、現在のnode_modulesを読み取り、どのパッケージをダウンロードする必要があるかを判断するのにかかる時間は、npmからすべてのパッケージを実際にダウンロードするのにかかる時間よりも大幅に長くなります。サーバー？ それを測定する実際の実験を見てみたいです。

そして、私もこの段落を理解していません-

npm ci bypasses a package’s package.json to install modules from a package’s lockfile. This ensures reproducible builds—you are getting exactly what you expect on every install.

npm iを実行すると、 package-lock.jsonファイル内の正確なバージョンが使用され、実行後のnode_modulesの状態は、実行後の状態と同じであるとここで結論付けただけではありません。 npm ci実行した後ですか？ したがって、ビルドも同様に再現可能になります。

アップデート：

私は次のテストを行いました-
新しいcreate-react-appプロジェクトを作成しました。 初期化が完了した後、7つの直接依存関係を持つpackage.jsonと、1982パッケージを含むpackage-lock.jsonがありました。
この状態（ node_modulesはすべての依存関係が含まれます）- npm iを実行すると

real    0m2.548s
user    0m2.659s
sys     0m0.182s

1つのパッケージフォルダ（ node_modules/babel-eslint ）を削除してから、もう一度npm iすると、時間がかかりました。

real    0m3.295s
user    0m3.543s
sys     0m0.434s

不足している依存関係を再ダウンロードするには

node_moduelsフォルダー全体を削除し、 npm i再度実行すると、時間がかかりました。

real    0m16.701s
user    0m19.251s
sys     0m10.379s

npm ciを実行したとき、

real    0m20.997s
user    0m23.844s
sys     0m14.857s

これは、1つのパッケージを削除しようとしたとき、または呼び出しの前にnode_modulesフォルダー全体を手動で削除しようとしたときでも、それほど違いはありませんでした。 とにかくnpm ciはnode_modulesのコンテンツを削除することから始まるので、それは驚くべきことではありません

実行するたびに、 diff -q -r node_modules_orig/ node_modules/を実行して、結果が元の依存関係と同じであることを確認しました。 いつもそうだった。

結論として、 node_modulesの現在の状態に関係なく、 npm ciは私のマシンで約21秒かかるようです。 最近複製されたプロジェクト（ node_modules ）でnpm iを使用すると、最大18秒かかり、依存関係が変更されていないプロジェクト（現在のnode_modulesは必要な依存関係と一致します）で実行します。 ）約3秒かかります。

では、いつnpm ciが望ましいでしょうか？ 速くはないようですが（もちろん、これは1つのテストにすぎません）、最終結果はnpm iと同じなので、後続のビルドも同様に信頼できます。

npm ciは、 package-lock.jsonにあるものだけが必要な場合に適しています。 npm iは、 package-lock.jsonにあるものを正確にインストールすることを保証するものではありません。 これは仕様によるものです。 package-lock.jsonはnpm iへの入力ですが、出力でもあります。

ソフト削除されたパッケージバージョンのように、 npm iが別のものをインストールする（したがってpackage-lock.jsonを変更する）ケースはほんのわずかしか残っていないと思います。

npm ciが最初に導入されたとき、 npm iはpackage-lock.json完全に無視したか、少なくともさまざまなバージョンのインストールにはるかに積極的でした。

いずれにせよ、それは本当に重要ではありません。 npm ciは、 node_modulesフォルダーがまだ存在しない場合にのみ問題ありません。 それ以外の場合、特にWindowsでは非常に遅くなります。 したがって、 npm iには、 package-lock.jsonを変更せず、 package-lock.json内にあるものを正確にインストールしないことを_保証_するフラグが必要です。

理由と方法についてさらに議論することに意味はありません。 取得するか、取得しないかのどちらかです。 現状では、 npm ci最悪です。

/アップデート：
npm iを実行するとpackage-lock.jsonが変更されるリポジトリは次のとおりです： https ：

変更は本質的に技術的なものにすぎませんが、それでも受け入れられません。

繰り返しますが、次のとおりです。

• npm ciは、設計上、常にnode_modulesのコンテンツを削除します。これは、速度が遅いため、非実稼働ビルドには望ましくありません。 ただし、 package-lock.jsonにあるパッケージの正確なバージョンを使用します。これは、複数の状況で望ましいことです。

• npm installはnode_modulesの内容を更新するだけで、非常にパフォーマンスが高くなりますが、設計上、 package.jsonバージョン番号が異なる場合、 package-lock.jsonの内容は無視されます。複数の状況では望ましくありません。

• npm install --package-lock-onlyはドキュメントで説明されています：

  --package-lock-only引数は、node_modulesをチェックして依存関係をダウンロードするのではなく、package-lock.jsonのみを更新します。

  これは、上記のどのシナリオでも役に立たないようです。

過去3年間に人々が求めてきたもの：

1. package.jsonを無視し、インストールされるパッケージの決定的なソースとしてpackage-lock.jsonを_only_尊重するコマンド（どこでも）。

2. node_modules内容全体が削除されたり、すべてが最初から再ダウンロードされたりすることはありません。

ドキュメントとローカルテストの両方からわかる限り、 npm installはポイント2を満たしますが、1は満たしません。 npm ciはポイント1を満たしますが、2は満たしません。 npm install --package-lock-onlyはなしを満たしますそれらの要件の。

この問題が解決された理由は完全にはわかりませんが、目的の動作を実現する方法はまだありません。

編集： @fuzzykillerの例を拡張するために、 package-lock.jsonが更新されるだけでpackage.jsonどこかにファジーな依存関係がリストされていて、それらの依存関係のバグ修正バージョンがリリースされた場合、新しいマシンでnpm installを実行すると変更されます。 突然、2台のマシンのインストールに違いが出ました。 私の会社では、まさにこの動作からバグに遭遇しました。 package-lock.jsonをGitに再度チェックインする必要があるだけではありません。

そのような状況では、 npm ciように動作するコマンドを使用することが望ましいです。これにより、 package-lock.json内容のみに基づいて再現可能なインストールが行われます。 ただし、 node_modulesフォルダーの内容を削除すると、最終的な本番ビルドには適切な動作であるにもかかわらず、一部の環境や状況ではビルドの速度が大幅に低下します。

この問題に対処するためのフラグがどこにでもある可能性があります。 npm install --from-lockfile可能性があります。 npm ci --preserve-existing可能性があります。 しかし、今のところ、 npm install追加するフラグを要求する人は誰でも、解決策としてnpm ciを指さされ、フラグを要求する人は誰でも、 npm ciは、解決策としてnpm installを指し示します。 この問題はnpm install --package-lock-only指してクローズされましたが、そのフラグは人々が求めているものとほぼ反対です。 信頼できるソースとしてpackage-lock.jsonを尊重せず、 node_modulesフォルダー内の依存関係を更新またはインストールしません:)

この問題は再開する必要があります。