プロジェクトの依存関係を管理するために、node.jsは他の多くのプラットフォームと同様に、独自のパッケージマネージャーnpmを提供します。 また、たとえばRuby Gemsに似ており、同じ機能を実行するように見えるという事実にもかかわらず、npmには、node.jsでアプリケーションを開発するときに考慮すべきいくつかの機能があります。 これらの機能の1つは、node_modulesディレクトリがプロジェクトに格納される方法です。 多くの場合、他のシステムと同様に、package.jsonのみをプロジェクト内のモジュールの固定バージョンに残し、node_modulesは.gitignoreに追加されます。 この戦略は常に正しいとは限りません。npmjs.orgのFAQに目を向けると、以下が表示されます。
Q：node_modulesをgitに保存する価値はありますか？
A：Mikeal Rogersはこの質問に非常によく答えました。
http://www.mikealrogers.com/posts/nodemodules-in-git.html
tl; dr
- Webサイトやアプリケーションなど、デプロイする必要があるプロジェクトのnode_modulesをgitに保存します。
- ライブラリおよび再利用可能なモジュールのnode_modulesを.gitignoreに追加します。
- npmを使用して、開発環境で依存関係を管理しますが、展開に使用されるスクリプトでは管理しません。
カットの下には、この珍しいアプローチが何に関連しているのかを詳細に説明しているMikeal Rogersによる記事の翻訳があります。
node.jsの世界で再考する必要がある問題の1つは、アプリケーションの依存関係の管理の問題です。
ノード0.4.0に伴う大きな変更の1つは、node_modulesのサポートでした。 この変更は重大な結果をもたらしました。 グローバルにインストールされたモジュールよりも、ローカルディレクトリ内のローカルモジュールの優先順位を上げました。 同時に、npmはデフォルト設定をグローバルからローカルに変更し、ローカルモジュールへのほぼ満場一致の移行を確認しました。
グローバルモジュールからローカルモジュールへの移行は、ノードを前世代のプラットフォームから区別するものです。 RubyとPythonはこの分野で完全に失敗し、標準的なプラクティスはプラットフォーム全体（virtualenv、rvm）の分離されたサンドボックスでの開発と展開であったという事実は失敗の認識です。
しかし、状況は改善しています。 ノードでのローカルモジュールのサポートにより、既知のプラットフォームではまだ達成されていないことを実現できます。競合や予期しない結果なしに、2つの依存関係が同じモジュールの完全に異なるバージョンを接続できます。 これには、モジュール名をローカルおよび再帰的に解決するために、カーネルにいくつかの高度なロジックが必要でした。 しかし、このようなサポートの最も重要な条件は、ノードプロセス全体でグローバルになるためにモジュールレベルの依存関係に依存してはならないということでした。
今では、初期段階で多少のしつこさがあるにもかかわらず、すでにローカルモジュールに慣れており、それに慣れています。 それでもなお、私たちは世界の昔から残してきた古い習慣を守り続けています。
グローバルインストール、特に名前の競合を解決するためのローカルモジュールよりもグローバルモジュールの利点を扱っていたとき、バージョン管理システムに依存関係を保存することは非常に悪い考えでした。 これは、主にオープンな嘘であるため、悪いです。 依存関係コードの存在は、同じモジュールがグローバルにインストールされた場合に使用されることを意味しません。 コードをある場所にデプロイし、1週間後に同じコードを別の場所にデプロイすると、両方のインストールが同じ依存関係セットを受け取ることを確認するために、重いデプロイメントツールを開発しました。 問題自体が不器用なので、これらのツールはすべて不器用です。
しかし、今はもうRubyやPythonではなく、node.jsであり、モジュールをさらに改善しました。 デプロイしているアプリケーションがある場合、バージョン管理システムのnode_modulesディレクトリにすべての依存関係を配置します。 デプロイにnpmを使用する場合は、bundleDependenciesでのみこれらのモジュールを接続します。 コンパイルが必要な依存関係がある場合は、コードをコミットし、デプロイ時にnpm rebuildを実行するだけです。
私はこれを言ってみんなバカだと言って、それから数週間後、彼らは私が正しいと言い、node_modulesをgitに置くことは展開と開発の両方にとって祝福だと言った。 これは客観的には優れていますが、発生するいくつかの質問/苦情は次のとおりです。
すべてのインストールが同じ依存関係を取得するようにバージョンをコミットしないのはなぜですか？
バージョンコミットは、最上位の依存関係のバージョンのみをコミットできます。 Expressを特定のバージョンにコミットし、3週間後にマシンにデプロイすると、npmはExpressの依存関係を再度解決し、マイナーな変更を伴う新しいバージョンの接続を受信する可能性があります。これにより、アプリケーションが最も不快でデバッグが困難になります。これは、リクエストが新しいマシンに送信される場合のみです。 それは悪夢になります、そうしないでください。
ライブラリのメンテナーに依存関係のバージョンも修正するように勧めないのはなぜですか？
これまで、npmレジストリには約5,500個のパッケージがあります（ 翻訳者のメモ：2011年12月現在のデータ、現在34,000個近くあります ）。 この1か月で、600を超える新しいパッケージが追加され、5,000を超えるパッケージが更新されました。 一部のパッケージについては、週の間にいくつかの更新がリリースされました。 コミュニティとして、統合テストの一部を自分たちの間で配布する必要があります。 ほとんどのメンテナーは、パッケージの依存関係に対応するすべての更新でパッケージをテストすることはできません。 これが、ライブラリ開発者がバージョンをコミットしてはならず、リポジトリへの依存関係をコミットしてはならない理由です。 依存関係をローカルで更新し、バグレポートを送信する新しい人が必要です。 コミュニティを前進させ、最新バージョンと新しいパッケージの最先端にとどまる必要があります。
デプロイが必要なアプリケーションのみがリポジトリにnode_modulesを保存する必要があります。 パッケージメンテナーは、依存関係について許容できるバージョン境界を自分で決定し続ける必要があります。 これは、node.jsで見られる多くの変更と改善により、コミュニティを形に保つ唯一の方法です。
node_modulesをリポジトリに保存すると、ソースツリーにアプリケーションに関連しないゴミが大量に作成されますか？
いいえ、あなたは間違っています、このコードはアプリケーションで使用されています。アプリケーションの一部であり、そうでないふりをすると、問題が発生します。 あなたは他の人のコードに依存しており、彼らは間違いを犯し、あなたより少なくない、おそらくもっと頻繁に新しいバグを生み出します。 すべてのコードをリポジトリに保存すると、アプリケーションでこれまでに変更されたすべての行を追跡できます。 これにより、git bisectをローカルで使用して、実稼働環境で結果が同じであり、実稼働環境のすべてのマシンが同一であることを確認できます。 依存関係の不明な変更を追跡する必要はありません。各行のすべての変更は、バージョン管理システムを通じて利用できます。
わかりました、今何をしますか？
まとめます。
- デプロイするアプリケーションのリポジトリにnode_modulesを格納しますが、サポートするライブラリのリポジトリには格納しません。
- コンパイルされたすべての依存関係は、ソースコードをコンパイル結果ではなくリポジトリに保存し、展開中にnpm rebuildを使用して収集する必要があります。
node_modulesを.gitignoreに追加したすべての人は、このがらくたを今日削除してください。 これは、私たちが取り残せないほど幸せな時代の遺物です。 グローバルモジュールの時代は終わりました。