作者 | Loraine Lawson
译者 | 许学文
策划 | 丁晓昀
Vue 3 的发布让其创始人尤雨溪吃了不少苦头，也让他知道，未来再处理框架升级时需要在策略上做出重大改变。
在 2023 年 VueConf 多伦多大会上，Vue.js 的创始人 尤雨溪 向与会者透露，在 Vue（一款用于构建用户界面的渐进式 JavaScript 框架） 从版本 2 升级到版本 3 的过程中，他犯了三大错误，并从中吸取到了一些教训。
1
错误一：一次发布太多微小但破坏性的变更
尤雨溪在 11 月发布的一段视频 中说道：“我们犯的第一个错误，是一次发布太多微小但破坏性的变更。问题的关键在于，单独的每个小变更都很容易处理，但是当这些变更合在一起时，所带来的复杂性会呈指数级增长。”
通过这个教训，他意识到在进行变更时，优先保持原有功能的可用性是明智之举。他进一步补充到，这一做法也将给框架维护者的工作流程带来变革，未来他们将采用逐步弃用的周期性原则进行框架升级。
“对于我们想要变更、破坏或移除的每一项内容，都应该始终首先保持其一切运行正常，然后再考虑弃用，同时应该引入一个新特性的可选阶段，此阶段在不破坏任何现有功能的前提下，允许用户自主选择是否采用新特性。最终，在未来版本中将那些需要废弃的特性移除。”
他解释说，Vue 的维护者将会在不同版本之间采取分阶段的变更策略，以避免再次出现“一大堆破坏性的变更同时发布”的情况。他将这个计划与 Angular 和 Ember 的升级方法进行了比较，这两个框架在主要版本之间都分散了小的破坏性变更，并且时间跨度相对较长。
“Vue 已经发展到了一个阶段，我相信长远发展所需的良好升级策略将变得至关重要。我们可以保证，在短期内，绝对不会考虑进行任何破坏性变更。对于长期来说，我希望 Vue 3 能成为稳定的基础版本，并且未来我们将会非常认真地对待这种变更。”
2
错误二：低估了升级对生态库的影响
尤雨溪说道，他学到的第二个教训是，在进行变更时要及时与生态库的作者联系，以确保在发布到注册中心之前解决与生态库适配的问题。
“导致第二个错误的原因，是我低估了升级对生态库的影响。我忽略了生态库的作者适配 Vue 3 所需要花费的工作量。”
由于他们对许多内部 API 和行为做了变更，对于依赖这些内部行为的大型库而言，升级到 Vue 3 变得“非常困难”。这导致了诸如 Nuxt、Beautify 等主要生态库的升级拖延时间很长。
“事实上，这些也是有互相依赖关系的应用因为升级难度而停滞在旧版本的首要原因之一。所以这里学到的教训是，生态系统依赖的重要性不容忽视。”
为了应对这种情况，Vue 采用了一个对生态系统进行自动化持续集成的系统，该系统可以自动测试 Vue 的所有核心变更与其上下游所依赖库的兼容情况。
“目前我们已经成功集成了超过 15 个项目到系统中，而且未来还将继续增加。在发布之前，可以针对每个提交运行所有这些下游库，这样就可以在发布之前检测出潜在问题。通过这个系统，我们还能够与这些生态库的作者密切合作，共同解决可能出现的问题，以确保在发布时一切都能够顺利进行。”
“Vue 不鼓励，甚至禁止生态库的作者们使用其内部 API，因为这是导致这类库升级困难的主要因素之一。”
“由于大多数项目都支持 TypeScript，现在我们可以在类型级别和运行时级别强制执行这一点。虽然我们仍需要向外部公开一些内部 API，以供官方工具或库使用。但对于无法直接控制的生态库，我们将从类型定义中移除这些私有 API，以防止这些库使用它们。”
3
错误三：分多个阶段发布
将发布分阶段是一个错误。Vue 3 的核心模块是在 2020 年 9 月发布的，然而，当时许多生态系统相关的部分仍在开发中。在发布 Vue 核心模块的稳定版时，官网文档的一个主要问题是，没有将组合 API 作为最高优先概念进行宣传。此外，在官方库、迁移指南、开发工具支持等方面也都存在一些遗漏。
“当时我们这样做的原因是，我们觉得应该先发布一些关键的东西，这样生态系统就有动力去尝试。但结果是，发布一个没有完整生态系统的版本会给早期的使用者带来了困惑。”
尤雨溪承认，在大版本发布中，最重要的应该是优先确保一切准备就绪，而不是匆忙发布。
“更重要的是，在大版本发布之前，应该先找到收集反馈的方法，并与库的维护者合作推进升级工作。这是与利益相关者和生态系统合作更主动积极地行为，这也是未来进行重大变更时要去改进的地方。”
4
Vue 3 做对了什么？
Vue 在这个版本中也做对了一些事情，第一个就是采用了 TypeScript。
“现在，对于前端解决方案来说类型检查是基本要求。任何一个主要的 TypeScript 或前端领域的解决方案，你只要观察一下就会发现 ，现在人们第一关注的就是其对 TypeScript 集成和支持情况。”
TypeScript 已经被证明在长期项目和大团队环境中极大增强了代码的可维护性。将代码库迁移到 TypeScript 也显著提高了 Vue 本身的可维护性，为未来的迭代奠定了坚实的基础。
另一个 Vue 做对的事情是采用了组合式 API。虽然一开始人们对改特性产生疑问，但对 Vue 来说效果很好。
“我们还记得早期引入 组合式 API 的时候。尽管它是受到了 React hooks 的启发，但它深深植于 Vue 自己的响应系统。虽然，在初期阶段引起不少争议。人们并不真正理解我们为什么要这样做。”
事实上，仍然有人更偏爱 Options API，但相对于组合式 API，它存在一些限制。这部分是因为 Vue 的用户群发生了变化。在早期，大多数用户关注的是小到中型的场景，主要解决的问题是如何与现有后端系统轻松集成。但随着时间的推移，Vue 的维护者们看到用户构建了更复杂且要求更高的场景，包括更大规模的单页面应用程序。
“首先，为了适应不断变化的用户群体，其次也为了满足行业不断变化的需求，我必须提供一些解决方案，来解决由这些新需求带来的问题，这就是可扩展性。因此，组合式 API 的创造就是试图在尽可能多地保留 Vue 原始的用户友好性的前提下，提供一种支持这种可扩展性的方法。”
那些采用组合式 API 的人会发现其真正的好处所在，他补充说。
”这样使社区的价值更大化，比如 VueUse，它为我们提供了一系列非常有用的实用工具，那些不适合在 Vue 核心模块中解决的问题，被社区很好地解决。事实上，我认为 VueUse 可能也是直接因组合式 API 最大受益者之一。”
Vue 还在投资开发者体验方面做出了正确的选择。实际上这也是当下流行的 Web 构建工具 Vite 诞生的原因，它起源于一个仅服务于 Vue 的开发服原型。现在，许多框架都在使用 Vite，包括 Nuxt。
通过对 IDE 的投资，Vue 见证了整个生态系统的受益，造福了 Web 开发者。这项投资孕育出了 Volar，这是一个包含 Vue 语言服务和 Vue TSC 的子项目的总项目，而 Vue TSC 是一个命令行界面，它封装了 TypeScript 并为 Vue 组件提供了命令行检查。
“和 Vite 类似，这整套工具最初也只服务于 Vue，但随后发展成了一个包括一系列工具的生态系统，旨在帮助框架构建更强大的 IDE 和支持 TypeScript。Volar 现在也正在发展成为一个独立于框架之外的核心模块，将来不仅支持 Vue，还要支持 Astro、MDX 以及其他可能采用它的框架。”
尤雨溪声称这是 Vue 生态系统独有的特性。“我们看到很多好的想法都是先从 Vue 生态系统开始，然后产生了比 Vue 生态系统更大的影响。”
最后，尤雨溪表示，Vue 3 实现了所设定的目标，包括更好的性能、更好的类型支持、更好的可扩展性和更好的开发体验。随着对 Vue 2 的支持在本月结束，Vue 3 的下载量已经接近 50%，Vue 3 的采用率在过去一年几乎翻了一番。
