API 验证器：开启 ReSharper 插件新时代
ReSharper 既是插件，也是强大的插件创建平台。 设计产品的各个方面时，ReSharper 开发团队采用了依赖项注入方法。 这就使 ReSharper 的任何组件都像一个可使用插件重写的构建块，为微调 ReSharper 行为带来无限可能。
作为插件作者，您可以利用 ReSharper 开发者自己使用的所有组件。 但这种自由度也有不利的一面。
“每个公共组件都是一个扩展点”的策略限制了我们重构现有代码的能力。 为进程外模式准备 ReSharper 或为集成到 Fleet 准备我们的代码库等大规模重构也因此变得更为困难。 多年来，我们一直表示 ReSharper 的每个新版本都与已安装的插件不兼容，即使它们引用的 API 集在技术上没有发生变化。 由于我们的内部重构，我们无法保证无缝迁移。
ReSharper 和 Rider 每年都会发布三个主要版本，因此直到最近，插件开发者每年都要被迫重新编译插件至少三次。 我们明白，这让插件编写者的工作颇为艰难，我们也意识到必须做出改变。
因此，我们开始考虑让 ReSharper 的平台自动检测其插件引用的 API 中的变化。
什么是 API 验证器？
在 ReSharper 中，我们将每个插件都视为产品的重要组成部分。 所有部件在安装期间组合。 在这个阶段，我们现在可以检测插件使用的 API 是否被更改或在最新版本的 ReSharper 中不再可用。
如果 API 验证器发出危险信号，该插件将被标记为 Incompatible（不兼容），不会添加到安装的产品中。 但是，它将保留在 ReSharper 内 Extension manager（扩展程序管理器）中的已安装插件列表中。
通过 API 验证的插件将自动迁移到产品的下一个版本。 ReSharper 2023.1 实际上是第二个包含 API 验证器的 ReSharper 版本，因此在 2023.1 版本之前兼容的所有插件都将被保留。
指定依赖项的新方式
引入 API 验证器的同时，我们还更改了指定与产品版本兼容性相关的依赖项的要求。 这需要讲一些背景。
在内部，我们把主要版本称为“wave”。 命名 wave 时，我们取发布年份的最后两位数字，再加上一位数字表示该年的版本编号。 例如，对于 2023 年的第一个主要版本，wave 名为“wave 231”，2022 年的第三个版本是“wave 223”。
在插件中将 wave 名称指定为依赖项有两种好处。 第一，它将帮助我们验证软件包确实是 ReSharper 的扩展程序。 第二，指定兼容 wave 的范围让您可以指示哪些版本的产品与插件兼容。
过去，我们建议为此使用区间表示法。 例如，如果您将区间表示法的范围指定为 [223-231)，则表示插件仅与 2022.3 版本兼容。 但是，引入 API 验证器后，我们现在建议不使用区间表示法指定 wave。 您可以将 231 指定为 wave 依赖项来声明向前兼容性，如下所示：
<dependencies> <dependency id="Wave" version="231.0.0"/> </dependencies>
Marketplace 集成
在安装期间执行的 API 验证器的代码也在 JetBrains Marketplace 中实现。 这对插件开发者来说是个好消息，因为当 SDK 中不再出现所用 API 时，插件的页面现在会显示详细警告。 在每个抢先体验预览或主要版本公开之前，会在所有可用插件上执行 API 验证。
JetBrains Marketplace 插件网页上的 API 验证结果示例。
插件开发者还可以选择在插件未通过验证流程时选择接收电子邮件通知。 这些电子邮件详细说明了哪些 API 已过时、被移除、更改或更新，帮助您将无法编译的部分归零，无需打开包含插件代码的项目。
为 ReSharper 或 Rider 编写插件时需要帮助？
- 加入我们的 Slack 频道，获得 JetBrains 团队的帮助并与其他插件开发者交流。
- 查看本文帮助您入门。
接下来有什么值得期待的？
目前，JetBrains Marketplace 中可见的产品兼容性信息仅供发布者使用。 我们不可能自动下架插件，即使我们确定它已经完全过时并且肯定与当前版本的 ReSharper 不兼容。 目前，我们在 Extension manager（扩展程序管理器）中显示这些插件可用，尽管任何安装它们的尝试都会失败，因为它们无法通过嵌入式验证。
将来，我们将从动态中清除此类插件。 带有插件的动态目前基于 wave 版本构建，而不是产品的实际构建号。 这意味着 ReSharper 2023.1 EAP 1 的插件列表与发布版本相同。 Marketplace 和 ReSharper 开发团队已经着手从基于 wave 的动态切换到基于构建的动态，敬请期待更多更新。
致谢
我们要感谢 Mike-E 的无限热情，感谢他让我们注意到实现这一功能的重要性。
本博文英文原作者：
