我应该使用 go mod 提交供应商目录吗？

IT行业相对于一般传统行业，发展更新速度更快，一旦停止了学习，很快就会被行业所淘汰。所以我们需要踏踏实实的不断学习，精进自己的技术，尤其是初学者。今天golang学习网给大家整理了《我应该使用 go mod 提交供应商目录吗？》，聊聊，我们一起来看看吧！

我在 go1.12 上使用 go 模块来处理我的 Go 依赖项。将 vendor/ 目录也提交到版本控制中是否是最佳实践？

这与提交 `vendor` 目录是否是最佳实践有关？在使用 dep 的情况下会问这个问题。使用 dep，提交 vendor/ 是获得真正可重现构建的唯一方法。那么 go 模块呢？

解决方案

我想提供一些支持提交 vendor、go.mod 和 go.sum 的论点。

我同意已接受答案的论点，即它在技术上是不必要的并且会使存储库膨胀。

但这里有一个支持论点的列表：

• 构建项目并不依赖于 Github/Gitlab/... 或 Go 代理服务器上可用的某些代码。开源项目可能会因为审查、作者激励、许可变更或我目前无法想到的其他一些原因而消失，其中 did happen on npm, the JavaScript package manager, and broke many projects。不在您的存储库中，不在您的代码中。

• 我们可能使用了内部或第 3 方 Go 模块（私有），这些模块也可能会消失或变得无法访问，但如果它们是在供应商中提交的，那么它们就是我们项目的一部分。 没有什么会意外发生。

• 私有 Go 模块可能不遵循语义版本控制，这意味着 Go 工具在动态获取它们时将依赖最新的提交哈希。回购历史记录可能会被重写（例如变基），并且您、同事或您的 CI 工作可能最终会为他们使用的依赖项得到不同的代码。

• 执行编译和构建步骤的 CI/CD 作业不会在每次执行 CI 作业时浪费时间和网络来下载依赖项。所有需要的依赖项都是本地的并且存在（go build -modvendor）

• 不需要设置 CI/CD 作业身份验证来下载私有 Go 模块（更简单）。

• Go 依赖项几乎总是文本文件（源代码），并且将它们存储在存储库中非常便宜。其他所有语言的情况并非如此。

• 承诺供应商有时可能会改进代码审查流程。通常，我们总是在单独的提交中提交依赖项更改，因此如果您好奇的话可以轻松查看它们。

这是一个与存储库膨胀相关的有趣观察。如果有人进行代码审查，并且团队成员包含了一个包含 300 个文件的新依赖项（或更新了一个包含 300 个文件更改的依赖项），那么深入了解并最终开始讨论替代方案/质量（如果需要）可能会很有趣。这实际上可能会减少二进制文件的大小和整体复杂性。

如果新合并请求中的 go.mod 中只有一个新行，我们很可能不会考虑它。

何时提交供应商是错误的？

vendor 永远不应该提交（想象一下您制作了新的 gorilla/mux）。仅适用于生成可执行二进制文件的项目。

除非您需要修改供应的包，否则您不应该这样做。 Go 模块已经为您提供了可重复的构建，因为 go.mod 文件记录了依赖项的确切版本并提交了哈希值，go 工具将尊重并遵循这些哈希值。

可以通过运行 go modvendor 命令来重新创建 vendor 目录，默认情况下甚至会被 go build 忽略，除非您要求它与 -mod=vendor 标志一起使用。

阅读更多详细信息：

Go wiki: How do I use vendoring with modules? Is vendoring going away?

Command go: Modules and vendoring

Command go: Make vendored copies of dependencies

理论要掌握，实操不能落！以上关于《我应该使用 go mod 提交供应商目录吗？》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！