签入node_module是社区标准,但现在我们也可以选择使用wrapwrap。后者对我来说更有意义,但是总会有人进行“强制发布”并引入错误。还有其他缺点吗?
我最喜欢的关于这个主题的文章/哲学可以追溯到2011年(在node.js领域很长一段时间):
https://web.archive.org/web/20150116024411/http://www.futurealoof.com/posts/nodemodules- in- git.html
直接引用:
如果您拥有要部署的应用程序,则将所有依赖项检入到node_modules中。如果使用npm进行部署,请仅为那些模块定义bundleDependencies。如果您有需要编译的依赖项,则仍应签入代码并在部署时运行$ npm rebuild。 我告诉过的每个人也告诉我我是个白痴,然后几周后告诉我我是对的,检查node_modules到git中对部署和开发是一种祝福。从客观上讲,它是更好的方法,但这是我似乎遇到的一些问题/投诉。
如果您拥有要部署的应用程序,则将所有依赖项检入到node_modules中。如果使用npm进行部署,请仅为那些模块定义bundleDependencies。如果您有需要编译的依赖项,则仍应签入代码并在部署时运行$ npm rebuild。
我告诉过的每个人也告诉我我是个白痴,然后几周后告诉我我是对的,检查node_modules到git中对部署和开发是一种祝福。从客观上讲,它是更好的方法,但这是我似乎遇到的一些问题/投诉。
我认为这仍然是最佳建议。
强制发布方案很少见,npm shrinkwrap可能对大多数人有用。但是,如果要部署到生产环境,则没有什么比检查整个node_modules目录更省心的了。
npm shrinkwrap
node_modules
或者,如果您确实不想检查node_modules目录,但希望更好地保证没有被强制推送,请遵循以下建议npm help shrinkwrap:
npm help shrinkwrap
如果要避免拜占庭作者用破坏应用程序的代码替换正在使用的程序包的任何风险,则可以修改收缩包装文件以使用git URL引用而不是版本号,以便npm始终从git中获取所有程序包。
当然,有人可以运行一个奇怪的git rebase东西或修改git commit哈希……但是现在我们变得疯狂了。
git rebase