錯誤做法

在升級 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 的解析策略