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