Changesets 的详细解释
下面是对 Changesets 的详细解释以及我们如何思考它们。
问题:
在组织软件包发布时,您可能最终希望对不同人在相对大的时间跨度内编写的几个更改进行分组。捕获此信息的最佳时间是在提交 PR 时(当它在你的脑海中还很新鲜时),而不是当你最终批量发布这些更改时。Git 不是存储此信息的好地方,因为它不鼓励编写详细的变更描述 - 您希望允许人们提供尽可能多的有关变更的文档。
解决方案,Changesets:
思考 changeset 的最好方法是将其与变更日志或版本提升分开,changeset 是一个“更改意图”。更改意图携带了两点关键信息:
- 版本控制
- 变更日志
由于它是一个更改意图,相关的版本控制信息是:
- 'major' | 'minor' | 'patch'
此外,在单仓库中,我们可以对任何其他应重新发布以使用此更改的单仓库包进行编码。这可以确保如果您升级所有包的最新版本,它们都是兼容的。当前的实现在很大程度上是由bolt (opens in a new tab)对版本兼容性的意见 inform 的。
- 变更日志信息可以存储为 markdown 代码段。由于直接在 git 中存储此信息有问题,因此我们使用以下结构将其存储在文件系统中:
-| .changeset/
-|-| UNIQUE_ID.md一个 changeset 是一个带有 YAML 前言的 Markdown 文件。Markdown 的内容是更改摘要,将写入变更日志,YAML 前言描述了哪些包已更改以及它们应该采用哪些语义化版本类型提升。
---
"@myproject/cli": major
"@myproject/core": minor
---
Change all the things这很有用,因为它将版本控制分为两个步骤:
-
添加 changeset - 可以在 PR 中由贡献者完成,而更改在他们的脑海中还很新鲜。
-
版本控制 - 组合所有 changeset,根据每个包的最大版本提升为每个包创建一个版本提升,并在需要时更新依赖项,编写变更日志。然后可以作为一个整体来审查。
使这一切变得有价值的工具
-
CLI 生成新的 changesets
-
自动使用 changesets 进行版本控制
-
在 PR 中检测和显示 changesets
用于从单仓库发布多个软件包的工具也很重要,但是不需要与此关联。
对单包仓库的好处
Changesets 首先且最重要的是处理多包仓库中的版本控制,其中系统中的相互依赖关系很重要,需要理解和捕获。从概念上讲,Changesets 的优势与此无关。我认为这个过程总体上改进了拉取请求,有助于增强对版本控制决策和变更日志条目的信心。