這是一個很好的問題。有利有弊。我討論這個話題，讓您可以對此做出自己的意見。
應該在 Git 中提交 node_modules 文件夾嗎？
我提到了 Git，但同樣的原則也適用於您所使用的任何版本控制系統。
這是一個很好的問題。有利有弊。
我建議的默認選擇是不提交 node_modules 文件夾，而是將其添加到您的.gitignore文件中。
您可能有特殊的需求，反過來改變這個決定。
我討論這個話題，讓您可以對此做出自己的意見。
以下是不提交 node_modules 的一些論點：
您可以保持 Git 歷史純淨。當您添加新的套件時，您只需存儲package.json和package-lock.json文件的更改。當您決定更新套件版本時，只需存儲package-lock.json的文件更改。
package-lock.json是 npm 的一個相對較新的功能，它取代了以前使用的“shrinkwrap”命令。
您避免將數百MB的依賴項放入您的存儲庫中，這意味著隨著時間的推移，工作速度將更快。切換分支和檢出代碼是受存儲庫大小影響很大的2個操作。
在使用分支時，您可能會遇到超出您的代碼範圍的合併衝突，而是涉及依賴代碼。這對您處理來說並不好，可能會浪費很多時間。避免提交更改依賴項後的合併請求或合併操作，將有更多的文件涉及到這個過程。工具變得更慢，甚至可能決定不顯示完整的差異（例如 GitHub）。
如果您在部署到與開發機器不同的平台時（常見情況是在 Mac 上開發，在 Linux 上部署），需要重新編譯原生的 Node 模塊。您需要調用npm rebuild，這會使服務器與開發機器不同步。
不提交 node_modules 意味著您需要將所有模塊列在package.json（和package-lock.json）中，這是必須的步驟。這很好，因為您可能不會很注意這樣做，如果您不這樣做，某些 npm 操作可能會出錯。
提示：在
package.json文件中不需要使用具體版本，自從引入了package-lock.json文件以後不再需要了。
如果您使用單獨的dependencies和devDependencies集合，通過提交node_modules文件夾，您基本上提交了devDependencies，而生產構建無法（輕易）去除它們。
可能會導致您提交 node_modules 的原因，以及如何解決它們：
npm套件可能被其作者從 npm 注冊表中刪除。在 2016 年發生過著名的left-pad事件（了解更多）。這在受歡迎的套件中非常少見。如果發生這種情況，您可能無法再使用那個特定的功能。
您還可以主張npm不能保證無限期存在，它可能會消失，所以確保將完整的代碼與您的應用程序一起提交，是確保將來擁有的一種簡單方法。
每次使用套件時，在 GitHub 上創建一個 fork。偶爾保持它與原始庫同步（可以自動化）。
這在某些情況下並不實用，因為套件可能有數十個它們自己的依賴項。
您可以為項目使用私有存儲庫服務器，並將其用於托管所有依賴項。
選項包括：
- sinopia
- npm_lazy
- npm-lazy-mirror
- artifactory
- npm Enterprise（來自 npm 公司）
提交依賴項的另一個原因是能夠快速編輯代碼，如果您發現錯誤或者想要向庫添加某些內容。
這是一把雙刃劍：如果這樣做，您就失去了升級套件的能力，如果有新版本發布，這只對於快速的臨時修復有好處。
最佳的解決方案是要麼向原始項目提交要求的 PR，要麼 fork 它並將您的 fork 用作依賴項。