“node_modules”文件夾是否應該包含在git存儲庫中

Question

我想知道我們是否應該在我們的 repo 中跟蹤 node_modules 或在檢查代碼時進行 npm install？

Answer 1

答案並不像Alberto Zaccagni 所說的那么簡單。 如果您開發應用程序（尤其是企業應用程序），在您的 git repo 中包含 node_modules 是一個可行的選擇，您選擇哪種替代方案取決於您的項目。

因為他很好地反對 node_modules，所以我將專注於他們的論點。

想象一下，您剛剛完成了企業應用程序，您將需要支持它 3-5 年。 你絕對不想依賴某人的 npm 模塊，因為它明天就會消失並且你不能再更新你的應用程序。

或者您擁有無法從 Internet 訪問的私有模塊，並且您無法在 Internet 上構建您的應用程序。 或者，您可能出於某種原因不想依賴於 npm 服務的最終構建。

您可以在這篇 Addy Osmani 文章中找到優缺點（雖然是關於 Bower，但情況幾乎相同）。 最后我會引用 Bower 主頁和 Addy 文章中的一段話：

“如果您編寫的包不是供其他人使用的（例如，您正在構建 Web 應用程序），則應始終將已安裝的包檢查到源代碼管理中。”

Answer 2

模塊詳細信息存儲在packages.json ，這就足夠了。 無需簽入node_modules 。

人們過去常常將node_modules存儲在版本控制中以鎖定模塊的依賴關系，但是現在不再需要npm node_modules了。

這一點的另一個理由，正如@ChrisCM 在評論中所寫：

另外值得注意的是，任何涉及本機擴展的模塊都不會在架構之間工作，需要重新構建。 提供不將它們包含在回購中的具體理由。

Answer 3

我建議不要檢查 node_modules，因為像 PhantomJS 和 node-sass 這樣的包，它們會為當前系統安裝適當的二進制文件。

這意味着，如果一個 Dev 在 Linux 上運行npm install並檢查 node_modules - 它不適用於在 Windows 上克隆 repo 的另一個 Dev。

最好檢查 npm install 下載的 tarball 並將npm-shrinkwrap.json指向它們。 您可以使用shrinkpack自動執行此過程。

Answer 4

這個話題很老了，我明白了。 但是由於 npm 生態系統中的情況發生了變化，我錯過了對此處提供的參數的一些更新。

我總是建議不要將 node_modules 置於版本控制之下。 到目前為止，在接受的答案中列出的幾乎所有這樣做的好處都已經過時了。

1. 已發布的包不能再輕易地從 npm 注冊表中撤銷了。 因此，您不必擔心失去項目之前依賴的依賴項。

2. 將 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 服務器），提供一些先前獲取的依賴項集以供下載。

Answer 5

不使用源代碼控制跟蹤node_modules是正確的選擇，因為某些 NodeJS 模塊（如 MongoDB NodeJS 驅動程序）使用 NodeJS C++ 附加組件。 這些附加組件是在運行npm install命令時編譯的。 因此，當您跟蹤node_modules目錄時，您可能會不小心提交特定於操作系統的二進制文件。

Answer 6

我同意ivoszz 的觀點，即檢查 node_modules 文件夾有時很有用，但是......

---

場景一：

一種情況：您使用從 npm 中刪除的包。 如果您在文件夾 node_modules 中擁有所有模塊，那么這對您來說就不成問題。 如果您在 package.json 中只有包名稱，則無法再獲取它。 如果一個包不到 24 小時，你可以很容易地從 npm 中刪除它。 如果超過 24 小時，則您需要與他們聯系。 但：

如果您聯系支持人員，他們將檢查刪除該版本的軟件包是否會破壞任何其他安裝。 如果是這樣，我們不會刪除它。

閱讀更多

所以這種情況的可能性很小，但有情況 2 ......

---

場景2：

另一種情況是：您開發了軟件的企業版或非常重要的軟件，並在 package.json 中寫入：

"dependencies": {
    "studpid-package": "~1.0.1"
}

您使用該包的方法function1(x) 。

現在，studpid-package 的開發人員將方法function1(x)重命名為function2(x)並且他們犯了一個錯誤......他們將他們的包版本從1.0.1更改為1.1.0 。 這是一個問題，因為當您下次調用npm install時，您將接受版本1.1.0因為您使用了波浪號（ "studpid-package": "~1.0.1" ）。

現在調用function1(x)可能會導致錯誤和問題。

---

但是：

將整個 node_modules 文件夾（通常超過 100 MB）推送到您的存儲庫，將消耗您的內存空間。 幾 kb（僅 package.json）與數百 MB（package.json & node_modules）相比......想想吧。

如果出現以下情況，您可以/應該考慮一下：

• 軟件非常重要。

• 當某些事情失敗時，它會花費您金錢。

• 你不信任 npm 注冊表。 npm 是中心化的，理論上可以關閉。

在 99.9% 的情況下，您不需要發布 node_modules 文件夾，如果：

• 您只為自己開發一個軟件。

• 你已經編寫了一些東西，只是想在 GitHub 上發布結果，因為其他人可能會對它感興趣。

---

如果您不希望 node_modules 位於您的存儲庫中，只需創建一個.gitignore文件並添加行node_modules 。

Answer 7

我想提供一個中間選擇。

1. 不要將node_modules添加到 git 中。
2. 使用package-lock.json文件來確定您的依賴版本。
3. 在您的 CI 或發布過程中，當您發布一個版本時，復制 node_modules 文件夾並備份它（例如在雲存儲中）。

在極少數情況下您無法訪問 NPM（或您使用的其他注冊表）或 NPM 中的特定包，您擁有 node_modules 的副本並且可以繼續工作，直到您恢復訪問權限。

Answer 8

還要考慮的另一件事：檢查node_modules會使使用dependencies和devDependencies之間的差異變得更加困難/不可能。

但另一方面，人們可以說將經過測試的完全相同的代碼推向生產是令人放心的——包括devDependencies 。

Answer 9

如果 package.json 中提到了依賴項，則不需要簽入 node_modules。 任何其他程序員都可以通過執行 npm install 簡單地獲得它，並且 npm 足夠智能，可以在項目的工作目錄中創建 node_modules。