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

Question

我在 go1.12 上使用 go 模块来处理我的 Go 依赖项。将目录也提交到版本控制中是否是最佳实践vendor/？这与提交 `vendor` 目录是否是最佳实践有关？在使用的情况下会问这个问题dep。使用dep，提交vendor/是获得真正可重复构建的唯一方法。那么 go 模块呢？

Answer 1

我想给出一些支持提交vendor、go.mod和的论据go.sum。

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

但这里有一个相反的论点列表：

• 构建项目并不依赖于 Github/Gitlab/... 或 Go 代理服务器上可用的某些代码。开源项目可能会因为审查、作者激励、许可变更或其他一些我目前无法想到的原因而消失，这种情况确实发生在 JavaScript 包管理器 npm 上，并破坏了许多项目。不在您的存储库中，不在您的代码中。

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

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

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

这是一个与存储库膨胀相关的有趣观察。如果我进行代码审查，并且团队成员包含了一个包含 300 个文件的新依赖项（或更新了一个包含 300 个文件更改的依赖项），我会非常好奇地深入研究该依赖项并开始讨论代码质量以及此更改的必要性或替代的 Go 模块。这实际上可能会减少二进制文件的大小和整体复杂性。

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

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

这些都是我的想法，如果我还记得什么，我会在这里补充。

Answer 2

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

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