versions上个月,我们正式向世界宣布了这个工具,从那时起,我一直在努力增加我认为会使这个工具更有用的功能。
今天我介绍一个新的小版本。v0.1.0, 但在这之前...
有什么变化?
从架构上看,versions 是非常简单的,它包括以下内容。
- 接收输入的
go.mod文件,这些文件代表 "项目 "或 "存储库"。 - 读取并解析这些
go.mod文件,目的是生成一个软件包的矩阵。 - 对每个
go.mod文件中的软件包进行分类。 - 确定一种方法来表明哪些软件包有相同和/或不同的版本。
- 打印出结果。
v0.0.1构建时考虑到了这些步骤。最初的目标是快速实现一个概念证明,一个可操作的原型,其工作目标只有一个:渲染有味道的markdown。这个目标已经实现了。
然而,这段代码的形状并不容易扩展,当然它完成了工作,但如果计划要继续前进并继续开发,它需要更多的思考。考虑到这一点,在发布新版本之前,我的下一个目标是两个。
- 清理和重构代码,使其更容易阅读和扩展,以支持渲染多种输出,调味的标记是第一个。
- 增加一个新的功能,可以被任何渲染输出所使用,这是为了确保新的重构代码对开发者友好。
清理和重构
很明显,需要将实际的解析与渲染(及其具体规则)分开。第一个版本假定flavored markdown是唯一支持的渲染输出,它包括适用于这种类型的具体渲染规则,并且与其他非渲染逻辑交织在一起。这一改变是为了在不久的将来能够添加更多的输出,比如JSON。
在v0.0.1 ,所有的东西都是用两个函数实现的。
versions.NewGoMods用于对解析后的go.mod值进行处理,和versions.PrintMarkdown来打印出实际的标记代码。
那么,我们如何从这个真正具体的实现变成更抽象的东西?
我思考的方式是在 v0.1.0的方式是在一个新的Versions 类型中定义最终结果。
// Versions contains the parsed go.mod files.
Versions struct {
Modules map[ModuleName]Module
GoVersions GoVersions
Packages Packages
}
这个类型的字段包含以三种不同方式组织的解析值。
- 具体来说,每个
go.mod文件包含什么,Modules字段,这包括Modules。ModuleGoVersions中的名称和围棋版本,以及其- 依赖性要求,以
Packages的地图形式出现。
- 所有正在使用的包,
Packages字段,内部组织为ModuleName, - 所有使用的Go版本,
GoVersions字段。
拥有这三个字段是允许不同的渲染器生成所需的基本层。 markdown这是到目前为止的具体例子,这个包只渲染结果,它仍然支持以前的选项,但现在它们不影响解析过程。
添加一个新的功能
在清理了代码和重构之后,第二个目标是增加一个新的功能。我认为添加LICENSE 支持是一个很好的练习,因为。
- 它涉及到一个基本类型。
Package因为许可证是按包计算的,可能会根据使用的具体版本而改变。 - 它增加了(假设的)新的依赖性,并且
- 它可能会影响渲染输出的实现方式。
因此,增加这样一个功能,可以让我这个versions 包的用户来确定用户体验的好坏(从开发的角度来说就是),来证实最终重构的代码是否更好。
最后,这是一个有趣的练习,证明了代码更容易操作,也导致了另一个不错的变化,即引入了 olekukonko/tablewriter的引入,以一种更易于用户阅读的方式呈现markdown代码。
总结
这一次,我想与通常的公告式的帖子有一点不同,而是通过我的思考过程和代码的演变来引导你。当然,versions 仍然处于起步阶段,但我认为不时地描述一下幕后的情况是有意义的。
要安装当前版本,你可以运行。
GO111MODULE=on go get github.com/MarioCarrion/versions/cmd/versions@v0.1.0
使用它和以前一样。
versions <full path to 1 go.mod> <full path to 2 go.mod> <full path to N go.mod>
祝你玩得愉快!