跳至主要内容

发行工作流

实验性

此功能仍在孵化中，我们很可能会根据你的反馈对其进行改进。

在使用单一存储库时，一项困难的任务通常是找出在开始新版本时哪些包应该接收新版本。Yarn 提供了一些工具，旨在让此工作流更轻松，而无需第三方工具（当然，你可能更喜欢不同实现提供的不同工作流！）。

自动更新的依赖项​

在运行 yarn version 命令以升级工作区的版本时，通过基本 semver 范围（^x.y.z、~x.y.z、...）依赖于第一个工作区的每个其他工作区都将自动更新以引用新版本。例如，假设我们有以下工作区

/packages/common (1.0.0)
/packages/server (depends on common@^1.0.0)
/packages/client (depends on common@^1.0.0)

在 2.0 之前，升级 common 需要您在其中运行命令，然后进入 server 和 client 手动升级它们的依赖项以引用新版本。但现在不需要了！如果我们在 common 中运行 yarn version 1.1.1，将应用以下更改

/packages/common (1.1.1)
/packages/server (depends on common@^1.1.1)
/packages/client (depends on common@^1.1.1)

当然，当 monorepo 中的包始终用于作为 monorepo 的一部分时，这并不重要，但当您使用多个要发布的包时，它会变得更加有趣。如果您忘记更新任一依赖包的范围，您的用户可能会下载旧版本的 common，该版本与较新版本不兼容。

延迟版本控制​

从 2.0 开始，yarn version 命令现在接受一个新标志：--deferred。设置此标志后，该命令将不会立即更改本地清单的 version 字段，而是内部记录一个条目，说明当前包需要在下一次发布周期中收到升级。例如，以下

yarn version minor --deferred

不会导致 package.json 文件发生更改！相反，Yarn 将在 .yarn/versions 目录中创建一个文件（或如果您在分支中，则重复使用）。此文件将记录请求的升级

releases:
  [email protected]: minor

然后稍后，一旦您准备好，只需运行 yarn version apply。然后，Yarn 将找到它先前保存的所有升级记录，并一次性应用它们（包括处理我们所见的升级内部依赖项）。

已签入的延迟记录​

我们在前一节中看到 yarn version patch 可以将未来版本存储在内部文件夹 .yarn/versions 中。但这是为什么呢？有什么好处呢？要回答这个问题，请考虑通过 monorepo 开发的流行开源项目。此项目接收许多外部拉取请求，但不会立即发布它们 - 它们通常作为批处理的一部分发布。每隔一段时间，首席维护人员会获取所有更改，将它们转换为新版本，并开始部署。

让我们关注必须将更改转换为版本的部分。这是如何工作的？这并不容易。以 Lerna 为例（monorepo 最流行的版本管理工具），你有两种解决方案

  • 在固定模式下，所有包都具有单个版本。因此，它们会一次全部升级。

  • 在独立模式下，你可以为每个源代码已更改的包选择一个版本。

不过，仍然有一个关键问题：即使你使用独立模式，你又如何知道哪些包需要升级？同样重要的是，它们应该是修补程序版本吗？次要版本？很难知道 - 大型项目每周可以收到几十个 PR，而跟踪哪些单元需要发布以及发布到哪个版本是一项非常困难的任务。

然而，使用 Yarn 的工作流，这一切都变得非常容易！由于升级保留在一个文件中，并且该文件神奇地绑定到一个 Git 分支，因此只需提交发行文件夹即可——所有预期的发行版都将成为项目历史的一部分，直到 yarn version apply 的时候——然后 Yarn 将使用所有单个记录，合并它们（因此需要次要版本的 PR 将比需要补丁的 PR 优先级更高），并同时应用它们。

作为一项额外福利，您甚至可以在典型的 PR 审查中审查软件包升级！这将产生将更多权力委托给您的社区的效果，同时能够确保每个人都遵守规则。

确保版本升级（CI）​

然而，提交延迟发布的一个问题是，确保您收到的 PR 包含正确的软件包发布定义变得很重要。例如，您应该能够相信该定义包含每个已修改工作区的发布策略（补丁、次要、主要，...）。

为了以自动化方式解决此问题，yarn version check 命令出现了。运行时，此命令将找出哪些软件包已更改以及它们是否列在发布定义文件中。如果它们没有列出，将抛出一个错误——假设您将其集成到 CI 系统（如 GitHub Actions）中——则会要求 PR 作者填写发布定义文件。

编写此文件可能会很繁琐；幸运的是 yarn version check 实现了一个非常方便的标志，名为 --interactive。设置时 (yarn version check --interactive)，Yarn 将打印一个终端界面，其中将汇总所有已更改的文件、所有已更改的工作区、所有相关的依赖工作区，以及每个条目的复选框，允许您选择要为每个工作区设置的发布策略。

当检查哪些文件已更改时，可以使用 changesetIgnorePatterns 配置选项来忽略文件。它对于排除不影响发布过程的文件（例如测试文件）很有用。

注意事项​

提交历史记录​

版本插件需要访问提交历史记录才能正确推断哪些包需要发布规范。特别是，在将 GitHub Actions 与 actions/checkout@v2 或更高版本一起使用时，Git 的默认行为是仅获取正在检查的版本，这会导致问题。要纠正此问题，您需要覆盖 fetch-depth 配置值以获取整个提交历史记录

- uses: actions/checkout@v2
  with:
    fetch-depth: 0