签入 node_modules 与 shrinkwrap

Posted

技术标签:

【中文标题】签入 node_modules 与 shrinkwrap【英文标题】:Check in node_modules vs. shrinkwrap 【发布时间】:2012-07-12 16:04:06 【问题描述】:

签入 node_module 是社区标准,但现在我们也可以选择使用 shrinkwrap。后者对我来说更有意义,但总有可能有人确实“强制发布”并引入了一个错误。还有其他缺点吗?

【问题讨论】:

【参考方案1】:

我最喜欢的关于这个主题的帖子/哲学可以追溯到 2011 年(在 node.js 领域很长一段时间):

https://web.archive.org/web/20150116024411/http://www.futurealoof.com/posts/nodemodules-in-git.html

直接引用:

如果您有要部署的应用程序,请将所有依赖项签入 node_modules。如果您使用 npm do deploy,只需为这些模块定义 bundleDependencies。如果您有需要编译的依赖项,您仍然应该签入代码并在部署时运行 $ npm rebuild。

我告诉过这个的每个人都告诉我我是个白痴,然后几周后告诉我我是对的,将 node_modules 签入 git 对部署和开发来说是一件好事。客观上更好,但这里有一些我似乎得到的问题/投诉。

我认为这仍然是最好的建议。

强制发布场景很少见,npm shrinkwrap 可能适用于大多数人。但是,如果您要部署到生产环境,没有什么比检查整个 node_modules 目录更能让您高枕无忧了。

或者,如果您真的、真的不想检查 node_modules 目录但想要更好地保证没有强制推送,我会遵循 npm help shrinkwrap 中的建议:

如果您想避免拜占庭作者用破坏您的应用程序的代码替换您正在使用的包的风险,您可以修改 shrinkwrap 文件以使用 git URL 引用而不是版本号,以便 npm 始终获取所有包来自 git。

当然,有人可以运行一个奇怪的 git rebase 或其他东西并修改一个 git 提交哈希......但现在我们快疯了。

【讨论】:

截至今天,该链接已损坏(500 错误),因此这里是该帖子的 archive (gist.github.com/3854887)。 如果作者删除了他们的包,这确实发生了,那么shrinkwrap 将无济于事。【参考方案2】:

npm FAQ 直接回答了这个问题:

将 node_modules 检入 git 以了解您部署的内容,例如网站 和应用程序。 不要将 node_modules 签入 git 中的库和模块 打算重复使用。 使用 npm 管理开发中的依赖项 环境,但不在您的部署脚本中。

引用自npm FAQ

【讨论】:

即使是常见问题解答也会发生变化。它现在显示为:“对于您部署的包,例如网站和应用程序,您应该使用 npm shrinkwrap 来锁定您的完整依赖关系树”。

以上是关于签入 node_modules 与 shrinkwrap的主要内容,如果未能解决你的问题,请参考以下文章

Heroku 构建失败:“node_modules 已签入源代码管理”

如何删除 node_modules 并在 ionic 2 项目中恢复它们

npm 安装,缺少 node_modules 文件夹

.tfignore 不忽略文件

如何在不更改修改后的时间戳的情况下签入文件?

Visual Studio Code:禁用特定文件类型的错误/警告签入