「node_modules」フォルダーをgitリポジトリに含める必要があります
リポジトリでnode_modulesを追跡する必要があるのか、コードをチェックアウトするときにnpmインストールを実行する必要があるのだろうか？
答えは、Alberto Zaccagniが示唆するほど簡単ではありません。アプリケーション（特にエンタープライズアプリケーション）を開発する場合、gitリポジトリにnode_modulesを含めることは実行可能な選択肢であり、選択する選択肢はプロジェクトによって異なります。
彼はnode_modulesに対して非常によく議論したので、それらの引数に集中します。
エンタープライズアプリを完成したばかりで、3〜5年間サポートする必要があると想像してください。明日姿を消し、アプリを更新することができない誰かのnpmモジュールに依存することは絶対に望まないでしょう。
または、インターネットからアクセスできないプライベートモジュールがあり、インターネット上でアプリを構築することはできません。または、何らかの理由でnpmサービスの最終ビルドに依存したくない場合があります。
長所と短所を見つけることができます このAddy Osmaniの記事で （それはBowerについてですが、ほぼ同じ状況です）。そして、私はBowerのホームページとAddyの記事からの引用で終わります。
「他のユーザーが使用することを意図したパッケージを作成していない場合（たとえば、Webアプリを構築している場合）、インストールされたパッケージを常にソース管理にチェックインする必要があります。」
モジュールの詳細はpackages.jsonに保存されています、それで十分です。 node_modulesをチェックインする必要はありません。
人々は、モジュールの依存関係をロックするためにバージョン管理にnode_modulesを保存していましたが、 npm shrinkwrap を使用することはもう必要ありません。
@ChrisCMがコメントで書いたように、この点の別の正当化：
また、注目に値するのは、ネイティブ拡張を含むモジュールはアーキテクチャ間で機能しないため、再構築する必要があることです。それらをレポに含めないことの具体的な正当化を提供します。
node_modulesをチェックしないことをお勧めします。たとえば、現在のシステムに適切なバイナリをインストールするPhantomJSやnode-sassなどのパッケージがあるためです。
これは、ある開発者がLinuxでnpm installを実行し、node_modulesをチェックインする場合、Windowsでリポジトリを複製する別の開発者では機能しないことを意味します。
Npmがダウンロードをインストールするtarballをチェックインし、npm-shrinkwrap.jsonをポイントすることをお勧めします。 shrinkpack を使用して、このプロセスを自動化できます。
MongoDB NodeJSドライバーのような一部のNodeJSモジュールはNodeJS C++アドオンを使用するため、ソース管理でnode_modulesを追跡しないのが正しい選択です。これらのアドオンは、npm installコマンドの実行時にコンパイルされます。したがって、node_modulesディレクトリを追跡すると、OS固有のバイナリファイルを誤ってコミットする可能性があります。
このトピックはかなり古いです。しかし、npmのecoシステムの状況が変わったため、ここで提供されている引数の更新を見逃しています。
Node_modulesをバージョン管理下に置かないことを常にお勧めします。受け入れられた答えの文脈でリストされているようにそうすることからのほとんどすべての利点は、現在のところかなり時代遅れです。
公開されたパッケージは、npmレジストリから簡単に取り消すことはできません。したがって、プロジェクトが以前に依存していた依存関係を失うことを恐れる必要はありません。
Package-json.lockファイルをVCSに配置すると、同じpackage.jsonファイルに依存しているにもかかわらず、頻繁に更新される依存関係が解決し、セットアップが異なる可能性があります。
そのため、オフラインビルドツールがある場合にnode_modulesをVCSに配置することが、残っている唯一の適格なユースケースと見なされる可能性があります。ただし、通常、node_modulesは非常に速く成長します。更新すると、多くのファイルが変更されます。そして、これはさまざまな方法でリポジトリに影響を与えています。長期的な影響を本当に考慮する場合、それも障害になる可能性があります。
Svnのような集中型VCSでは、コミットおよびチェックアウトされたファイルをネットワーク経由で転送する必要があります。これは、node_modulesフォルダーのチェックアウトまたは更新に関しては非常に遅くなります。
Gitに関しては、この多数の追加ファイルが即座にリポジトリを汚染します。 gitはファイルのバージョン間の違いを追跡するのではなく、単一の文字が変更されるとすぐにファイルのいずれかのバージョンのコピーを保存することに注意してください。依存関係が更新されるたびに、別の大きな変更セットが作成されます。バックアップとリモート同期に影響するため、gitリポジトリはすぐに巨大になります。後でgitリポジトリからnode_modulesを削除することを決定した場合、歴史的な理由から、それはまだその一部です。 gitリポジトリをリモートサーバーに（たとえばバックアップ用に）配布している場合、クリーンアップは別の苦痛でエラーが発生しやすいタスクです。
したがって、効率的なプロセスを重視し、物事を「小さく」保ちたい場合は、以前に取得したダウンロード用の依存関係のセットを提供するNexos Repository（またはZipアーカイブを備えたHTTPサーバー）などの個別のアーティファクトリポジトリを使用します。
私は ivoszz に同意します-時々役立つ node_modulesフォルダーをチェックするbut ...
シナリオ1：
1つのシナリオ：npmから削除されるパッケージを使用します。 node_modulesフォルダーにすべてのモジュールがある場合、それは問題になりません。 package.jsonにのみパッケージ名がある場合、それを取得することはできません。パッケージが24時間未満の場合、npmから簡単に削除できます。 24時間以上経過している場合は、連絡する必要があります。しかし：
サポートに連絡する場合、パッケージのそのバージョンを削除すると他のインストールが壊れるかどうかを確認します。その場合、削除しません。
そのため、この可能性は低いですが、シナリオ2があります...
シナリオ2：
これが当てはまる別のシナリオ：ソフトウェアまたは非常に重要なソフトウェアのエンタープライズバージョンを開発し、package.jsonに記述します。
"dependencies": {
"studpid-package": "~1.0.1"
}
そのパッケージのfunction1(x)メソッドを使用します。
現在、studpid-packageの開発者はメソッドの名前をfunction1(x)to function2(x)に変更し、障害を起こします...パッケージのバージョンを1.0.1から1.1.0に変更します。これは問題です。次回npm installを呼び出すときに、チルダ（1.1.0）を使用したため、バージョン"studpid-package": "~1.0.1"を受け入れることになります。
function1(x)を呼び出すと、エラーや問題が発生する可能性があります。
しかし：
Node_modulesフォルダー全体（多くの場合100 MB以上）をリポジトリーにプッシュすると、メモリースペースが消費されます。数百MB（package.jsonおよびnode_modules）と比較して、数KB（package.jsonのみ）...考えてみてください。
あなたそれをすることができた/それについて考えるべきである if：
ソフトウェアは非常に重要です。
何かが失敗するとお金がかかります。
npmレジストリを信頼していません。 npmは集中化されており、理論的にはシャットダウンできます。
次の場合、99.9％のケースでnode_modulesフォルダーを公開するために必要ない
あなただけのソフトウェアを開発します。
あなたは何かをプログラムしていて、GitHubに結果を公開したいだけです。他の誰かが興味を持っているかもしれないからです。
Node_modulesをリポジトリーに入れたくない場合は、.gitignoreファイルを作成し、node_modules行を追加します。
package.jsonに依存関係が記載されている場合、node_modulesをチェックインする必要はありません。他のプログラマはnpm installを実行するだけで簡単に取得できます。npmは、プロジェクトの作業ディレクトリにnode_modulesを作成するのに十分スマートです。
考慮すべきもう1つの点：node_modulesをチェックインすると、dependenciesとdevDependenciesの違いを使用することが難しく/不可能になります。
一方で、テストを通過したコードとまったく同じコードをプッシュすることは安心です。つまり、devDependenciesも含まれます。