如何使用v2+版本制作Go模块；是否避免导入路径前缀要求？

这是针对：

该库当前在v7版本上，我们希望将其迁移到go模块中。该库当前从其他库导入，如下所示：

// go.mod
require github.com/twitchtv/twirp v7.2.0+incompatible

// .go code
import "github.com/twitchtv/twirp"

// go.mod
require github.com/twitchtv/twirp v7.2.0

// .go code
import "github.com/twitchtv/twirp/v7"

如果我们在库中添加一个

go.mod

文件，现在每个其他库都会被迫更改导入路径，如下所示：

// go.mod
require github.com/twitchtv/twirp v7.2.0+incompatible

// .go code
import "github.com/twitchtv/twirp"

// go.mod
require github.com/twitchtv/twirp v7.2.0

// .go code
import "github.com/twitchtv/twirp/v7"

我们如何迁移Twirp库以使用go模块，而不强制其他库更新其导入路径

这里的主要问题是，单个服务可能会导入在不同版本上生成的多个Twirp客户端，并使用依赖于特定类型的帮助器函数。强制导入路径更新将强制所有这些帮助器函数同时需要管理旧类型和新类型，并且我们不能为所有类型生成别名（某些类型是函数）。这将创建一个升级锁。这是否意味着Twirp库需要永远处于

+不兼容的
模式

我们如何迁移Twirp库以使用go模块，而不强制其他库更新其导入路径

你不能

如果您的
go.mod
将模块声明为
github.com/twitchtv/twirp/v7
，则每个客户端库（以及您自己的包）都必须更新导入路径。这就是语义导入路径在Go模块中的工作方式

如果您使用
v1
或
v0
模块路径（编写时没有后缀），则您违反了semver合同，因为您的项目实际上已经有
v7
标记

这里的主要问题是，单个服务可能会导入在不同版本上生成的多个Twirp客户端

迁移到Go模块以一种干净的方式明确地解决了这一问题，即导入项目多个版本的客户端只需将导入声明为
github.com/twitchtv/twirp/vX
等，从而在
.Go
文件中立即显示出它们正在使用的版本

事实上，你有一个非常简单的方法来处理这个问题。只需迁移到Go模块，将模块声明为下一个主要版本后缀
github.com/twitchtv/twirp/v8
，然后将其标记为
v8.x.y
。从semver的角度来看，这是正确的，因为您的更改确实正在中断—您的客户机必须更改导入路径

这样，确实希望迁移到您的Go模块版本的客户机将知道需要做什么，并处理切换到新的主要版本的影响，包括重写导入路径。不想迁移的客户端可以继续导入
v7.x.y
（或更少）作为
+不兼容的
从该模块导入的项目将需要更新，但没有办法。如果他们不想更改导入，但导入路径必须更改，则可以选择使用
replace
。如果您库的用户希望将v7和v9导入到同一代码中，则必须提供v7和v9版本，并且这些版本必须在导入路径中具有不同的版本后缀。使用“如果我们在库中添加go.mod文件，那么现在其他所有库都将被迫像这样更改导入路径[…]”，您似乎暗示这对库的用户来说是一个问题。事实并非如此。这就是模块的工作方式。在大型代码库（包括测试、合并请求和审阅）上替换该导入路径需要45分钟。问题不在于需要不同版本twirp的客户端，而在于处理来自多个客户端的
twirp.Error
等类型的帮助器函数。第三级依赖项将阻止升级。无论客户端是否更新到新版本并更改其导入路径，都不会更新任何内容，直到所有要求这些客户端更新其所有帮助程序函数以同时处理
twirp.Error
（对于旧客户端）和
twirpv8.Error
（对于新客户端）的服务都会更新。这似乎是一个大麻烦。@tothemario我理解，我认为升级到v8的建议仍然适用。只要你用semver发出主要变化的信号，所有提供帮助函数的人都会自己升级一个主要函数，或者为v8类型添加新的处理程序。那些同时导入twirp和第三方助手包的人将相应地升级他们的dep。但这不是你能控制的。您可以做的是提供与semver兼容的适当升级和有关如何迁移的文档。使用版本或导入路径欺骗更糟糕。