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

【问题标题】：Should I commit vendor directory with go mod?我应该使用 go mod 提交供应商目录吗？
【发布时间】：2021-06-15 20:12:38
【问题描述】：

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

这与Is it best-practice to commit the `vendor` directory? 有点相关，它在使用dep 的情况下提出这个问题。使用dep，提交vendor/ 是获得真正可重复构建的唯一方法。 go 模块呢？

【问题讨论】：

【解决方案1】：

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

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

【讨论】：

在其他一些情况下，供应模块可能有意义，这可能值得一提：如果模块是从不切实际或不可能从 CI/构建脚本访问的私有仓库导入的，或者如果您担心它可能由于服务器不稳定或其他原因而消失，或者您正在使用GopherJS, which doesn't support modules yet :)
如果您不打算将出售的模块提交到 repo，出售的意义何在？
“go mod vendor”是否需要访问互联网？这可能是 @Flimzy 提到的 CI / 构建脚本中的问题
IMO 这个答案不好，甚至可能对新的 Go 开发人员有害。从 github 中删除依赖项项目时会发生什么？为什么 Kubernetes 项目（以及更多项目）放置并提交他们的供应商文件夹？
@icza 直到什么时候？ Go 代理公共服务提供什么保证，当项目从 github 中删除时，它们将（以及持续多长时间）继续提供 Go 模块？如果由于 github 和 Go 代理服务的某些审查而删除了依赖项怎么办？关键是所有这些假设和期望都不受我们控制，而供应商提交的包是本地的，并且在我们的项目中完全在我们的控制之下。

【解决方案2】：

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

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

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

构建项目不依赖于 Github/Gitlab/... 或 Go 代理服务器上的某些代码。开源项目可能会因为审查、作者激励、许可变更或其他一些我目前无法想到的原因而消失，did happen on npm, the JavaScript package manager, and broke many projects。 不在您的存储库中，不在您的代码中。
我们可能使用了内部或第 3 方 Go 模块（私有），这些模块也可能会消失或无法访问，但如果它们在供应商中提交，它们就是我们项目的一部分。 没有意外中断。
私有 Go 模块可能不遵循语义版本控制，这意味着 Go 工具在动态获取它们时将依赖最新的提交哈希。回购历史可能会被重写（例如 rebase），您、同事或您的 CI 工作最终可能会为他们使用的依赖项编写不同的代码。
承诺供应商可以改进您的代码审查流程。通常，我们总是在单独的提交中提交依赖项更改，因此如果您感到好奇，可以轻松查看它们。

这里有一个关于膨胀回购的有趣观察。如果我进行代码审查并且团队成员包含了一个包含 300 个文件的新依赖项（或者更新了一个包含 300 个文件更改的依赖项），我会非常好奇地深入研究它并开始讨论代码质量，这种更改的必要性或替代 Go 模块。这实际上可能会降低您的二进制文件大小和整体复杂性。

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

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

这些都在我头上，如果我记得还有什么，我会在这里添加。

【讨论】：