我正在遵循'官方'建议检查所有外部依赖关系到git(文章http://www.mikealrogers.com/posts/nodemodules-in-git.html链接到常见问题解答)时遇到问题
您如何确保不仅登记了顶级依赖项?大多数npm模块目前不遵循该建议.它们都在.gitignore中有node_modules.只是删除他们的.gitignore似乎有风险.
对于已编译的模块,本文建议仅签入源并运行'npm rebuild'和部署时间.不幸的是'npm rebuild'并没有为所有模块做'干净的制作'(尽管我正在使用的npm版本1.0.106中包含了错误修复https://github.com/isaacs/npm/issues/1872).这意味着我必须阻止编译目标(否则我将在生产机器上为开发人员机器编译目标代码,而不会被npm rebuild覆盖).但是:我该怎么做?不幸的是模块没有公共的编译输出目录,所以只需git-ignoring"node_modules// build"和"/ node_modules //out /"(如本文中提到的eng.yammer.com/blog/2012/) 1/4/managing-nodejs-dependencies-and-deployments-at-yammer.html在每种情况下都无济于事.
简短版本:如何确保生产服务器使用与开发期间使用的所有相关模块完全相同的版本?
更新:现在npm shrinkwrap
解决了锁定精确依赖版本的问题,甚至是依赖项的依赖项!更多信息请点击这里。
签入node_modules
可能会出现问题,因为它运行的环境可能因用户而异 - 因此在某些环境上编译的内容可能不适用于另一个环境。另外,它会用第 3 方代码填充您的变更日志和存储库。我认为这是您通过问题的简短版本得出的结论,所以让我来解决这个问题。
简短版本:如何确保生产服务器使用与开发期间使用的所有依赖模块完全相同的版本?
在你的里面package.json
,会有dependencies: {}
,如果没有,那么添加它。要完成您想要的任务,请将依赖项添加为键,并将其确切版本添加为值。例如dependencies: { docpad: '2.5.0', mocha: '1.1.0' }
但是,通常(取决于作者)升级到修订号(xxX 号)只是错误修复并且安全。您可以允许进行微小的更改,dependencies: { docpad: '2.5.x', mocha: '1.1.x' }
这样您就不必在每次有错误修复版本时更新 package.json 并进行发布。2.x
如果您愿意,您甚至可以做类似的事情。
这是我为所有模块使用的解决方案,因为它确保即使 6 个月后或无论什么模块仍然可以工作 - 而做类似的事情意味着当>= 2.0.0
依赖项的 v3 出现时,你的模块可能会到时候不能用。确保您坚持使用特定版本可以“保证”随着时间的推移的稳定性。
作为参考,您可以在此处查看我是如何在我的开源 Node.js 模块中完成此操作的
归档时间: |
|
查看次数: |
1973 次 |
最近记录: |