错误做法
在升级 Vue 3 的过程中，Vue 团队有一些做的不好的地方，也从中吸取了一些教训。
太多破坏性更改
首先，每个变更都可能引发许多小的破坏性修改。尽管看似可以单独管理每项变更，但由于变更之间存在关联，因此复杂性呈指数级增长。
由此认识到：
- 要对于想要更改或删除的内容，确保其正常运行后再进行修改。
- 对于新增的功能，应该有一个逐步引入的阶段。在这个阶段中，新的功能应该在特定标志下引入，允许用户选择性使用，这样用户可以根据自己的需求和偏好来决定是否使用新功能，而不会破坏其他内容。
- 最终，对于已经弃用的功能，应该在未来的版本中逐步删除。在删除之前，应该确保这些功能不会对现有用户造成任何影响，并提前通知用户有关弃用和删除的计划。
- Vue 维护者也会分阶段进行版本变更，避免在一个版本中出现大量重大变化。
长远来看，这些策略对于 Vue 的发展至关重要。在短期内，Vue 不会考虑任何重大变化，而是专注于改进和优化现有的功能。未来，希望 Vue 3 能够成为一个稳定的基础，为 Vue 的进一步发展提供坚实的基础。
关注生态系统
第二个错误是低估了 Vue 3 升级对生态系统库的影响。Vue 团队原本认为，在面临如此巨大的工作量时，库的开发者不需要将他们的现有库调整为 Vue 3 的兼容版本。
结果是，当 Vue 3 进行了许多内部 API 和其他内部行为的变更时，依赖这些内部行为的大型库升级到 Vue 3 变得非常困难。这导致了主要生态系统库（如 Nuxt 和 Beautify）的升级过程变得漫长而复杂。
由此认识到：生态系统依赖性至关重要。
为了有效应对这些潜在问题，Vue 引入了一个生态系统自动化持续集成系统，该系统专门针对 Vue 核心的下游生态系统依赖和依赖 Vue 的下游项目进行测试。
目前，已经成功集成了超过 15 个项目，未来还将继续增加。在每次提交变更之后，该系统都会对所有下游库进行测试，确保在发布前就能发现潜在的问题。一旦发现问题，可以与这些生态系统库的作者合作，解决可能出现的兼容性问题。
除此之外，Vue 团队希望明确禁止使用内部 API，因为他们发现这些内部 API 是导致库子组使用 Vue 时遇到困难的主要因素。
幸运的是，随着 TypeScript 在大多数项目中的普及，现在可以在类型级别和运行时级别实施这种禁止。对于官方工具或库，仍需要公开一些内部 API 以实现连接。然而，对于无法直接控制的生态系统库，将逐步从类型定义中移除这些私有 API，以确保如果这些库试图使用它们时就会引发错误。
同时发布所有内容
第三个错误就是：分开发布。Vue 3 核心在 2020 年 9 月发布，然而许多生态系统组件仍在开发中。初期文档存在一些问题，并且 composition API 没有在文档中作为首要概念进行介绍。在 Vue 核心稳定版发布时，官方库、迁移构建和开发工具支持尚未完善。
Vue 团队之所以这样做，是因为认为这些功能很重要，能够尽早推出，以鼓励生态系统中的库和开发者开始尝试和使用新的功能。这样做的结果就是，在没有完整的生态系统支持的情况下发布，给很多早期采用者带来了困惑。
尤雨溪表示，在一个重大发布中，重要的是要确保一切都准备就绪，而不是匆忙发布。
更重要的是，在发布大型版本之前，需要积极主动地与利益相关者和生态系统合作，通过与库维护者进行合作，收集反馈并提前升级项目。这种合作方式可以更加积极主动地推动生态系统的改进和发展。如果希望在未来实现更大的变更，这一点是必须要改进的。
正确做法
当然，在升级 Vue 3 的过程中，也有很多好的做法，下面就来详细看一看。
使用 TypeScript
使用 TypeScript 是最正确的做法之一。
现在，类型检查已成为前端解决方案的必备要素。当我们审视主要的前端解决方案时，可以发现 TypeScript 的集成和支持已成为人们首要关注的事项。
采用 TypeScript 已被证明在长期项目和大型团队环境中显著提高了代码的可维护性。在 Vue 的代码库中使用 TypeScript 也极大地增强了 Vue 自身的可维护性，为未来的迭代和扩展打下了坚实的基础。
Composition API
第二个正确的做法是采用了组合式 API。最初这受到了人们的质疑，但对于 Vue 来说效果非常好。引入组合式 API 时，它受到了 React hooks 的启发，但是它根植于 Vue 自己的响应性系统。
实际上，仍然有人喜欢 Options API，但它存在一些组合式 API 没有的限制。这部分原因是 Vue 的用户群体已经发生了变化。在早期，大多数用户关注的是小到中型使用案例，重点是易于集成到现有的后端系统中。但随着时间的推移，Vue 的维护者们看到用户构建了更复杂和要求更高的使用案例，以及大规模单页面应用。
为了让 Vue 适应不断变化的用户群体和行业需求，我们必须提出一些解决新问题的新方法，其中可扩展性是其中一个主要问题。因此，组合式 API 本质上是为了解决这种可扩展性问题而发明的，旨在提供一种解锁这种可扩展性的方法，同时尽可能地保留根植于 Vue 的用户友好性。虽然在早期有很多争议，但 Vue 团队的决策最终被证明是正确的。
那些采用组合式 API 的开发者发现它确实有很多好处。组合式 API 的出现也催生了强大的社区努力，例如 VueUse，它提供了一系列极其有用的实用程序，解决了许多问题。这些问题并不适合包含在 Vue 核心中，但社区很好地解决了这些问题。事实上，VueUse 可能是直接由组合式 API 带来的最大好处之一。
开发者体验
Vue 在开发者体验方面做出了明智的选择，这一点也得到了回报。这一选择促成了备受欢迎的 Web 构建工具 Vite 的诞生，它源自一个专为 Vue 开发的开发服务器原型。如今，许多框架都在利用 Vite，包括 Nuxt。
Vue 对其 IDE 方面的投资也已经取得了丰厚的回报，形成了一个扩展的生态系统，使 Web 开发人员受益良多。这些 IDE 投入催生了 Volar 的诞生，它是一个子项目的总称，涵盖了 Vue 语言服务器和 Vue TSC。Vue TSC 是一个命令行界面，它包装了 TypeScript，并为 Vue 组件提供了命令行时间检查功能。
这套工具最初仅为 Vue 而设计，类似于 Vite，但现在已经扩展成为一个工具集生态系统，帮助其他框架构建更出色的 IDE 和 TypeScript 支持。Volar 目前正逐步转变成一个框架无关的核心，不仅支持 Vue，还支持 Astro、MDX 等其他可能采用它的框架。
这是 Vue 生态系统所独有的现象，我们看到很多源自生态系统的创新理念开始产生比 Vue 生态系统更大的影响。
Vue 3 更好且不断增长
Vue 3 成功实现了他们设定的目标，包括提供更好的性能、更强大的类型支持、更优秀的可扩展性和更优的开发者体验。随着 Vue 2 的支持在本月结束，Vue 3 的下载量已经接近 Vue 总下载量的 48.8%。在过去一年中，Vue 3 的采用率几乎翻了一番。这表明 Vue 3 在迅速赢得开发者的青睐和信任，并在前端开发领域产生了深远的影响。
展望未来
- 稳定性是关键
- 在可预见的未来不会出现 Vue 2 到 3 这种重大变更
- 专注于可无缝采用的改进，例如：
- 响应式系统/解析器优化
- Vapor Mode：可选，类似与 solid 的解析策略
