node_modules文件夹通常不会上传到Git或SVN等源代码控制中。它往往是一个庞大的文件夹，每次推送/拉取都会很麻烦。
此外，一些模块包含C++代码，并在安装时编译为用户的操作系统。我可能与安装它的用户有不同的操作系统，因此如果我盲目地从源代码控制下载他的已编译版本的该模块，则该模块将无法工作。
相反，会包含一个小的配置文件，例如package.json，其中描述了项目所需的模块。当您运行$ npm install时，包管理器（npm或yarn）会读取该文件并开始下载它引用的模块。
每次部署或克隆项目时，计算机会从其存储库下载源代码，但不包括模块（因为它们不在源代码控制中），然后人或机器运行$ npm install以获取相关/必需的模块。
现在，项目会在远程服务器上一直部署；即将项目部署到生产服务器或在远程CI服务器上运行测试，甚至由其他开发人员在其本地机器上克隆。我工作的项目每天至少在远程CI服务器上部署和测试5次；每当我们向远程存储库推送提交时。
由于该用户删除了很多依赖模块，全球范围内许多$ npm install都开始失败。许多人无法将更新推送到其生产服务器上的项目，其他开发人员无法在其机器上获取该项目以进行工作等...
为防止这些问题，npm引入了一个政策，禁止取消发布超过72小时的模块：
来自npm：
注册表数据是不可变的，这意味着一旦发布，包就不能更改。出于安全和依赖于这些软件包的用户的稳定性的原因，我们这样做。因此，如果您曾经发布过名为“bob”的版本1.1.0的软件包，则其他软件包永远无法以该名称和版本发布。即使取消发布该软件包也是如此。但是，由于意外情况的发生，我们允许用户在72小时内取消发布他们刚创建的软件包。
npm install 吗？我可以想象出一些不修改依赖项的项目更新。 - lightspeed$ npm install，安装的模块将与 package.json 描述的相符。 - nicholaswmin
npm install。好吧，想一想。它将尝试下载已删除的软件包并失败，因为它不存在。 - Isaac Vidrinegit push命令即可。正如Nik Kyriakides所说，这一点非常美妙。 - Isaac Vidrine