好的，我有一点奇怪的情况。我有一个节点应用程序将交付给无法访问互联网的系统。我的 package.json 文件中有我所有的 deps，但是当我交付服务器时，我无法运行 npm install。
目前 node_modules 目录正在被检入 SVN。到目前为止，我讨厌这个，因为每次我需要获取模块的更新版本时，我都会从 SVN 中删除整个模块，安装更新版本，将其添加到 SVN 并签入。
我的其他选择是在打包节点应用程序以进行交付时进行某种构建，该构建会执行 npm install。也许从 SVN 签出的东西，npm 安装并创建必要的 tarball 或 rpm。
我过去曾为 ruby 使用过'bundler'，这非常好，因为你只需将所有的 deps 放在另一个目录中，它就会拉入这些 deps。如果您处于离线状态，效果很好。节点有类似的东西吗？
在寻找类似的答案时，我发现了这篇关于为什么将完整的node_modules 保留在源代码控制中的意义的文章：
虽然它是从 2011 年 12 月 10 日开始的，但现在可能有点过时了。
更新：在 2014 年 1 月，将所有node_modules存储在源代码管理中的建议仍然适用。
有一个名为shrinkpack的 CLI可以帮助您管理这个。
它通过读取生成的依赖关系图npm shrinkwrap并重新指向每个依赖项（和子依赖项）的https:// url 来代替指向项目中node_shrinkwrap目录中的 tarball 来工作。
node_shrinkwrap目录包含与从 npm 注册表下载的完全相同的 .tgz 文件，并且 - 由于存在文件（由创建和更新） -知道使用本地找到的 tarball 进行安装，而不是通过网络访问 npm 注册表.npm installnpm-shrinkwrap.jsonnpm shrinkwrapshrinkpacknpm install
npm install -g shrinkpack
我也面临着类似的部署场景，我从搜索中遵循的解决方案依赖于使用 make（unix 工具）并编写我自己的 Makefile。Makefile 是一个文本文件，它遵循特定的格式，您可以在其中创建目标，例如：测试、发布、安装。每个目标都是一段 Bash 代码，当您从命令行调用时会运行，例如：'make publish ' 或者您可以将它们链接在一起，例如 'make test publish'。
因此，在我的场景中，我有一个执行测试的“测试”目标，然后我有一个执行几件事的“发布”目标，例如调用“npm install”然后“npm prune”（删除我停止使用的旧 npm 依赖项）。然后通过将文件夹的 gzip 压缩到一个单独的位置来完成“发布”，然后将代码推送到我的生产服务器可以从中下载和解压缩的 Intranet 位置。所有 node_modules 代码都在 zip 文件中。在生产服务器上，运营团队提取 gzip，然后调用“make start”。'start' 只是设置任何环境变量并启动我的节点应用程序的另一个目标。
总而言之，我在源代码控制中有我的 node_modules 并且我发现 makefile 非常可定制，因此它非常适合具有不同需求的不同项目，但是您可以保持目标命名的约定，因此对其他团队来说很容易-工作人员和 DevOps 来测试/发布/安装您的应用程序。
问候，路易斯。