Turbopack Dev 現已穩定

這是一段漫長的旅程，但我們很高興地宣布 next dev --turbo 現已穩定，並準備好加速您的開發體驗。我們一直在使用它來迭代 vercel.com、nextjs.org、v0 以及我們所有的其他應用程式，並獲得了極佳的成果。

自 8 年前發布以來，Next.js 已被用於建構各種專案，從週末的業餘專案到複雜的企業應用程式。當 Next.js 首次發布時，webpack 明顯是框架捆綁基礎的最佳選擇，但隨著時間的推移，它已難以跟上現代 Web 開發人員的需求。我們的社群開始發現，在等待路由載入、程式碼變更反映以及生產版本部署時，迭代速度慢得令人痛苦。

我們投入了大量的時間和精力來優化 webpack，但在某個時候，我們覺得投入的努力沒有獲得足夠的改進。我們需要一個新的基礎，可以支援當今已在生產環境中運行的許多 Next.js 應用程式，以及我們計劃的未來創新，例如 React 伺服器元件。

以下是我們對這個新捆綁器的要求：

最小的重大變更
同時支援 App Router 和 Pages Router
所有規模程式碼庫更快的編譯時間
開發版本與生產版本高度一致
進階生產優化（例如，模組內的 Tree Shaking）
支援多個環境（如 Node.js 和瀏覽器）的模組圖
維護人員和進階使用者可全面觀察

我們評估了當時所有現有的解決方案，發現每個解決方案都有權衡取捨，與我們的要求和目標不符。從頭開始設計一些能夠完全滿足 Next.js 當今需求的東西，並掌握路線圖，以便我們可以建構和試驗它未來需要的東西，這對我們來說是有意義的。這是我們創建 Turbopack 的動機。

我們首先優化開發體驗，這也是我們今天發布穩定版本的原因。我們一直在 Vercel 的應用程式中廣泛地使用 Turbopack，並且顯著提高了我們開發人員的迭代速度。例如，對於 vercel.com 這個大型 Next.js 應用程式，我們發現：

本地伺服器啟動速度提升高達 76.7%。
使用 Fast Refresh 時，程式碼更新速度提升高達 96.3%。
在沒有快取的情況下，初始路由編譯速度提升高達 45.8%（Turbopack 尚無磁碟快取）。

在這篇文章中，我們將討論我們如何實現這些成果，以及其他一些亮點。我們還將明確說明對此版本的期望，並提供接下來的路線圖。

重點

更快的初始路由編譯

我們從社群聽到的最大問題之一是路由在開發環境中載入時間過長，這歸因於 webpack 的編譯速度。Next.js 會按需編譯路由，以避免在需要之前編譯所有可能的路由，這可以保持初始啟動速度快且記憶體使用量較低，但即使如此，您仍然可能會發現自己因為等待單個頁面載入而感到焦躁。

公平地說，像 webpack 這樣的捆綁器在幕後做了很多工作。首次編譯路由時，捆綁器會從「入口點」開始。對於 Next.js，它是 page.tsx 以及該路由的所有相關檔案（例如 layout.tsx 和 loading.tsx 等）的組合。這些入口點被解析以查找 import 語句，這些語句會解析為檔案，然後對這些檔案進行與入口點相同的處理，並且此循環會一直持續到找不到更多導入為止。此過程會建構一個模組圖，該模組圖不僅可以由 TypeScript / JavaScript 模組（包括 node_modules）組成，還可以由 CSS 檔案（包括全域和 CSS 模組）以及靜態檔案（例如 next/image 導入的圖片）組成。

在收集完所有模組後，模組圖用於建立 JavaScript 捆綁包，通常稱為「chunks」（區塊）。這些區塊是編譯器的輸出，可以在伺服器（在建構時或運行時）或瀏覽器中運行。

webpack 不支援建立為多個環境產生輸出的圖，因此我們今天必須在 Next.js 中使用 webpack 運行至少兩個單獨的編譯器，一個用於伺服器，一個用於瀏覽器。我們必須先編譯伺服器模組圖，以便可以找到所有對 "use client" 的引用。伺服器建構完成後，我們遍歷其圖，為瀏覽器編譯器建立相關的入口點。由於這是一個單獨的 webpack 編譯器，因此此過程中存在一些額外負擔，例如在用戶端和伺服器端之間解析相同的程式碼兩次。

使用 Turbopack，我們著手消除運行多個編譯器以及在它們之間協調的額外負擔。解決方案是讓編譯器意識到多個不同的輸出目標。在內部，這些稱為目標「轉換」。我們可以將導入標記為從伺服器到瀏覽器或從瀏覽器到伺服器的轉換。這就是 Turbopack 能夠有效捆綁伺服器元件和用戶端元件，以及從用戶端元件導入的伺服器函數的原因。

除了提高效能之外，使用單個編譯器在單次傳遞中處理多個環境還具有可靠性和偵錯優勢，因為我們不再需要在 Next.js 中協調兩個單獨的編譯器進程。

webpack 和 Turbopack 之間的另一個重大區別是，Turbopack 可以跨多個 CPU 並行化工作，而對於 webpack，只有使用 SWC 的 TypeScript / JavaScript 轉換步驟是並行化的。

webpack 不支援跨 CPU 並行化，因為為了有效地並行化，資料必須易於跨執行緒訪問。webpack 的建構方式大量使用大型 JavaScript 物件，這些物件無法在沒有昂貴的序列化和反序列化的情況下輕鬆地跨執行緒共享。這種額外負擔通常會抵消利用多個 CPU 帶來的效能提升。Turbopack 是用 Rust 编写的，它沒有相同的限制，並且從一開始就考慮了並行化。

我們還通過更快的檔案系統讀寫、更快的模組解析以及跳過更多無副作用模組的工作，從而獲得效能提升。

當在 vercel.com 這個大型 Next.js 應用程式上使用 Turbopack 時，我們發現初始編譯速度比使用 webpack 的 Next.js 快了 45.8%。

更快的 Fast Refresh

Fast Refresh 是捆綁器用來將變更傳播到您目前在瀏覽器中查看的路由的系統，有時稱為熱模組替換 (HMR)。

Next.js 具有更深入的整合，將 Fast Refresh 連接到 React，確保 React 在您變更元件時不會丟失狀態。

使用 webpack，我們發現當您達到一定數量的 JavaScript 模組時，Fast Refresh 的效能會受到限制。Webpack 需要執行圖遍歷並為即使沒有變更的模組產生輸出，並隨著 JavaScript 模組的數量線性擴展。

我們發現，在大約 30,000 個模組時，程式碼變更始終至少有 1 秒的額外負擔來處理更新，無論變更是否很小。例如，變更 CSS 檔案中的顏色可能需要 1 秒才能顯示在螢幕上。

這種效能對我們來說是不可接受的。我們認為，增量建構應該僅根據本地變更的大小進行擴展，而不是路由或應用程式的大小。當 button.tsx 變更時，編譯器應該只需要運行與該檔案變更相關的工作，而不必重新計算不受變更影響的其他模組和輸出檔案。為了應對這種情況，我們優先考慮了 Turbopack 中的基礎，該基礎允許對工作進行非常精細的重新計算。

這種努力轉化為底層函式庫 Turbo Engine，它使用自動按需驅動的增量計算架構，可在數十毫秒內提供大型 Next.js 和 React 應用程式的互動式熱重新載入。這種架構基於十多年的研究和現有技術，包括 webpack、Salsa、Parcel、Adapton 和 Rust 編譯器的查詢系統。

現在有了 Turbopack，Fast Refresh 速度會隨著您的變更大小而擴展，這就是我們能夠在像 vercel.com 這樣的大型 Next.js 應用程式上實現 96.3% 更快的程式碼更新速度的原因。

進階追蹤

隨著 Next.js 多年來的廣泛採用，我們發現越來越難以重現 GitHub 上報告的問題，尤其是與編譯器效能和記憶體使用量相關的問題。這是因為大多數人無法共享他們的應用程式程式碼，或者當他們共享程式碼時，應用程式無法運行，因為它需要資料庫或其他設定。

為了開始解決這個問題，我們在 Next.js 的內部結構中添加了追蹤功能。這些追蹤資訊會寫入 .next 資料夾中的檔案，並且不包含應用程式程式碼 — 僅包含檔案路徑、編譯器在該檔案上花費的時間以及其他計時資訊（例如個別轉換）。但是，對於 webpack，我們從來沒有一種好的方法可以清楚地區分編譯器的記憶體使用量與框架或應用程式程式碼的記憶體使用量，因為它們都在同一個 Node.js 實例中運行。

使用 Turbopack，我們能夠從一開始就進行儀器設計。我們在 Turbo Engine 中實作了一個儀器層，允許收集每個單獨函數的計時資訊。我們能夠擴展這些追蹤資訊，以追蹤每個函數的記憶體分配、解除分配和持久化記憶體。

這種新的進階追蹤功能為我們提供了深入調查速度變慢和記憶體使用量所需的所有資訊；它只需要追蹤資訊，而不是完整的程式碼庫。

為了處理這些新的追蹤資訊，我們實作了一個自訂追蹤檢視器，無論應用程式和追蹤資訊大小如何，它都能保持效能。它是一個專門為調查 Turbopack 的速度變慢和記憶體使用量而建構的追蹤檢視器，並且由於它縮短了回饋迴圈，因此使我們能夠優化許多早期採用者應用程式的效能。

雖然追蹤檢視器最初是為內部使用而建構的（並且適用於需要深入技術探討的情況），但我們已經實作了在 Next.js 中自行運行的必要組件。您可以使用這些說明產生 Turbopack 追蹤資訊。然後，當產生追蹤資訊後，您可以使用 next internal turbo-trace-server .next/trace-turbopack 啟動伺服器，以便檢查追蹤資訊。此處提供了一個追蹤檢視器的快速影片概述：點擊這裡。

更少的編譯時間波動

當將 Next.js 與 webpack 一起使用時，編譯時間通常不夠透明。在某些情況下，打開頁面可能需要 10 秒，而在另一些情況下，可能需要 20 秒。雖然可能存在快取，但它有時沒有足夠的影響來產生一致的結果。即使在沒有快取的編譯中，我們也看到了一些差異。

Turbopack 的底層架構確保編譯時間的差異更加一致。路由的編譯時間僅變化幾個百分比，這使我們能夠持續優化編譯器效能。

開發版本與生產版本高度一致

為了使用 webpack 優化編譯速度，我們不得不接受一些權衡取捨，這導致開發環境和生產環境有所不同。這些權衡取捨的一些範例是我們使用 style-loader，它將樣式注入到頁面中，並允許對它們進行 Fast Refresh，而無需重新載入頁面。但是，這意味著樣式在開發環境中由 JavaScript 注入，這會導致未設定樣式的內容閃爍。我們繞過了這種未設定樣式的內容閃爍，因此您不會看到它。另一個範例是，使用 webpack 的 Next.js 使用 eval-source-map，這意味著所有程式碼都包裝在 eval 中，並且來源地圖包含在其中，這確保了來源地圖在開發環境中可用，但代價是捆綁的程式碼更難以檢查和偵錯。雖然 webpack 支援使用 source-map 選項輸出完整的來源地圖，但它會對編譯時間和記憶體使用量產生過大的影響。

對於 Turbopack，我們著手預設解決這些問題，輸出 CSS 檔案和來源地圖，而不使用 eval。Turbopack 利用 sections 來源地圖，這是來源地圖規格中相對較新的部分，允許更有效地合併來源地圖輸出。在我們之前必須在一個位置產生所有映射的地方，我們現在能夠更精細地產生和快取它們。

Turbopack 中的 CSS 處理始終輸出 CSS 檔案，並且與 JavaScript 處理類似，它可以通過 Turbopack 開發運行時的一部分機制更新 CSS 檔案，而無需刷新瀏覽器。

我們現在可以自信地說，當使用 Turbopack 在開發環境中運作某項功能時，它在生產環境中也能運作並且行為相同。

我們的第一個穩定版本

兩年前，我們在 Next.js 13 中推出了 Turbopack 的 Alpha 版本，預覽了其效能潛力。雖然最初的結果很有希望，但它僅支援基本用法 — 許多 Next.js 功能（例如 basePath）尚未實作。

在接下來的一年中，我們專注於添加缺少的 Next.js 和捆綁功能。根據社群的回饋，我們決定完全專注於 next dev 體驗，以便我們可以解決最常見的迭代速度問題。到去年 Next.js Conf 時，90% 的開發測試都已通過，並且 Vercel 開發人員已經在日常開發中使用 Turbopack。

在 4 月，我們發布了 Next.js 14.2，其中 99.8% 的測試通過，並在不久之後達到 100%。從那時起，我們解決了 GitHub 上報告的問題，尤其是關於 npm 套件、Fast Refresh 和錯誤位置準確性的問題。

誠然，達到穩定版本的道路漫長，但這主要歸因於 Next.js 廣泛的測試套件，它為穩定性設定了很高的標準。我們花了 8 年的時間來發現邊緣情況，並添加了 6,599 個開發測試，這些測試也需要在 Turbopack 中通過。另一個因素是我們使用與 webpack 完全不同的架構設計了 Turbopack。簡單地將 webpack 移植到 Rust 會更容易，但無法解鎖我們想要實現的效能提升。

現在 Turbopack 通過了所有測試，已經過頂級 npm 套件的驗證，並且早期採用者的回饋已得到解決，我們準備將其標記為穩定版本。

到底什麼是穩定版本？

過去這一直是一個令人困惑的點，因此我們將在本節中闡明此版本為 Next.js 社群解鎖的功能。

此版本專門將 next dev --turbo 命令標記為穩定版本。生產版本建構 (next build --turbo) 尚不受支援，但請繼續閱讀以獲取更新，因為它們正在進行中。我們最終計劃在 Next.js 之外發布 Turbopack 的獨立版本，但我們希望首先通過增強 Next.js 社群的體驗來證明其價值。

除了我們將在下一節中介紹的不受支援的功能外，Turbopack 應該適用於 Next.js 的所有穩定功能。為了清楚起見，Turbopack 同時支援 App Router 和 Pages Router。實驗性功能可能適用於或不適用於 Turbopack，但它們肯定會在被標記為穩定版本時適用。

如果您的應用程式具有 webpack 自訂，但僅添加了 webpack 加載器，您可能已經可以通過為 Turbopack 配置加載器來使用 Turbopack。您可以閱讀文件，了解 Turbopack 中對 webpack 加載器的支援。

以下是經過驗證可與 Turbopack 搭配使用的 webpack 加載器列表：

@svgr/webpack
babel-loader
url-loader
file-loader
raw-loader
tsconfig-paths-webpack-plugin — 開箱即用，無需外掛程式。
大多數其他加載器也適用，因為我們支援 webpack 加載器 API 的子集。

大多數 CSS 和 CSS-in-JS 函式庫都受支援

受支援
- Tailwind CSS
- @emotion/react
- Sass
- styled-components
- Bootstrap
- Antd
- node-sass
- JSS
- Emotion
- theme-ui (使用 Emotion)
- @chakra-ui/core (搭配 Emotion)
- aphrodite
目前不受支援
- Less — 您可以添加 less-loader。使用 webpack 的 Next.js 也預設不支援 Less。
- @vanilla-extract/css — 使用自訂 webpack 外掛程式 — 我們將研究在未來支援所需 Hook 的方法。
- StyleX — 需要 Babel 轉換和對 data: 屬性的支援 — 我們將在 next build --turbo 穩定後研究支援 StyleX 的方法。

效能

我們要強調的是，今天發布版本的效能顯著優於 webpack，但這並非最終的效能數字。我們一直遵循 Kent Beck 的著名公式：「先求有，再求好，後求快 (Make it work. Make it good. Make it fast.)」。到目前為止，我們的大部分努力都投入在「先求有」階段，因為我們必須趕上 Next.js 和 webpack 的範疇，它們已經發展成熟將近十年。

Turbopack 大量押注其快取基礎架構，但您可能知道，快取是軟體開發中僅有的兩個難題之一。從經驗中，我們知道在並非專門為快取而建構的架構中新增快取，可能會導致不良的結果，因此我們甚至為最細微的功能都啟用了快取。這表示重建速度極快，但代價是冷啟動和記憶體使用量較高，而我們正努力朝更好的平衡發展。最棒的是，我們可以運用文章前面提到的進階追蹤功能，找出效率低下的地方，並分析哪些功能最值得快取。

在過去的 3 個月中，我們已經做出了一些顯著的改進。比較 Next.js 15 RC 2 中的 Turbopack 與 15 RC 1 中的 Turbopack，即可看出這些最佳化的成果

記憶體使用量平均減少 25-35%。
對於具有數千個模組的大型頁面，初始編譯速度加快 30-50%。

Turbopack 的穩定版本包含一個記憶體快取，每次重新啟動開發伺服器時都必須重建，對於大型應用程式來說，這可能需要十秒或更長時間。我們對於在磁碟持久快取測試中看到的重大成果感到非常興奮，我們將在本篇文章稍後介紹。

重大變更

建構我們自己的 bundler 的一大動機是，需要盡可能地符合 webpack 現有的行為，這是我們當時無法透過任何現有解決方案保證的。這包括檔案解析的方式，以及 webpack 的較小功能，例如某些 npm 套件使用的 webpackIgnore 註解。

遺憾的是，為了讓 Turbopack 和相關的 Next.js 實作能夠適應未來發展，我們確實必須移除一些功能。當您使用 webpack 時，仍然會支援這些功能。

以下是一些重點，讓我們深入探討我們必須變更這些功能的原因

不支援 webpack() 設定。 Turbopack 不是 webpack，它沒有相同的設定選項結構，儘管它確實支援許多相同的功能。具體來說，我們已實作對 webpack loaders 和 resolve aliases 的支援。大多數轉換程式碼的 webpack loaders 都已開箱即用。有些執行特殊操作的 webpack loaders，例如 webpack 子編譯器和發射檔案，則不支援。

.babelrc 不會自動轉換程式碼。 Turbopack 預設使用 SWC。您仍然可以根據需要新增 babel-loader，但我們要確保預設值始終快速，並且這些預設值在架構方面也合理。即使您設定 .babelrc，我們也始終必須執行 SWC，才能處理其他最佳化。這類似於 webpack 始終必須執行 acorn 解析器才能進行進一步最佳化的方式。如果您將 SWC 而非 Babel 與 Turbopack 一起使用，我們可以解析一次，並在整個 Turbopack 中端對端地運用相同的抽象語法樹 (AST)。

一些較少使用的 CSS Modules 功能。 我們已將 CSS 的處理從 PostCSS 切換到 Lightning CSS。Lightning CSS 是一個速度快很多的 CSS 編譯器，開箱即用支援 CSS 轉換、最小化和 CSS Modules。其代價是一些較少使用的功能不受支援。具體來說，:global 和 :local 偽選擇器 (它們的函式變體 :global() 和 :local() 仍然有效)、@value 和 :import / :export ICSS 規則。它也比其他 CSS 解析器更嚴格，並且會指出程式碼中的錯誤，而不是忽略它們。

在新增 Lightning CSS 的過程中，我們已回饋到該專案。例如，我們為 CSS Modules 實作了細微的選項，以停用 CSS grid 前綴和 CSS Modules 的 pure 模式。這讓從 webpack 中的 css-loader 轉換過來的 CSS Modules 更容易採用 Lightning CSS。我們也改進了對不受支援的 CSS Modules 功能的錯誤訊息。

我們感謝 Lightning CSS 的作者和維護者 Devon Govett，感謝他在專案上的持續合作。

實驗性功能。 由於我們專注於 Turbopack 在 Next.js 中的穩定性，因此我們決定優先專注於 Next.js 中提供的穩定功能。

如需完整清單，請參閱文件頁面。

Roadmap

Turbopack 已經走了很長一段路，但仍有許多工作要做。即將推出的兩個令人興奮的功能是持久快取和生產版本。我們預期推出順序大致如下

持久快取 — 未來次要版本
Builds beta — 未來次要版本
Builds release candidate — 未來次要版本
Builds stable — 未來次要版本
建議在 create-next-app 中用於新的應用程式 — 未來次要版本
當您沒有自訂 webpack 設定時，Next.js 中的預設值 — 未來主要版本

雖然 webpack 將繼續保留在 Next.js 中，但我們預期由於 Turbopack 的優勢，大多數 Next.js 應用程式都會想要使用它。一旦 Turbopack 的生產版本完成，我們將開始支援常用的 webpack 外掛程式。

我們對 Turbopack 的未來發展有粗略的計畫，但我們希望將這篇文章限制在我們有信心在可預見的未來發布的功能上。我們可能只談論兩個功能，但其中包含了很多內容，因此值得深入探討。

持久快取 (跨重新啟動的快速重新整理)

持久快取表示儲存編譯器完成的工作，以便在重新啟動開發伺服器或多個生產版本之間重複使用。

簡而言之，Turbopack 避免重複執行相同的工作，即使您重新啟動也是如此。

如「更快的快速重新整理」章節所述，我們建構了 Turbo Engine，以確保工作可以平行化和快取，以便每當您變更檔案時，我們只需要執行與該檔案變更相關的工作。如果我們可以在重新啟動和開啟路由時為您提供這種體驗呢？我們就不必重新執行先前開發階段已完成的編譯工作。如果我們可以獲得快速重新整理的優勢，但適用於開啟先前開發階段編譯的路由，以及使用 next build 的多個版本呢？

這正是我們一直在努力的方向：Turbo Engine 的新儲存層，支援將編譯工作持久儲存到磁碟，並在重新啟動開發伺服器或再次建構時還原它。

雖然 webpack 在 Next.js 中預設啟用了磁碟快取，但它有相當多的限制。值得注意的是，為了運作，必須從磁碟還原並讀取到記憶體中的快取佔很大一部分。它從未真正感覺到有足夠細微的快取。例如，在 Vercel 上的較大型應用程式中，我們發現當快取增長到足夠大的尺寸時，webpack 磁碟快取甚至可能比從頭開始執行所有工作還要慢。

與 webpack 現有的磁碟快取不同，Turbopack 的持久快取真正感覺像是跨重新啟動的快速重新整理。第一次編譯需要超過 10 秒的路由，一旦編譯過一次，從快取還原只需不到 500 毫秒。

我們在 Turbopack 的 next build 中看到了類似的結果，只有變更的檔案會重新編譯，其他所有內容都保持不變。在 next build 採取的許多步驟中，這將大部分時間從執行編譯和捆綁移轉到執行 TypeScript 類型檢查。

持久快取目前正在進行中，因為我們想先使用我們的內部 Next.js 應用程式來驗證它。初步結果非常樂觀，隨著我們不斷最佳化這些熱路徑，效能將會隨著時間的推移變得更好。

一旦持久快取穩定，它將預設啟用。啟用持久快取不需要變更您的程式碼庫。

如果您有興趣測試持久快取，請聯絡我們！

生產版本

我們很高興分享，我們在 Turbopack 的穩定生產版本方面取得了實質性的進展。目前，我們的生產測試有 96% 通過，這是一大進步。但是，在我們能夠有信心地建議大規模生產環境使用 Turbopack 之前，仍有一些領域需要更多努力。

與開發環境相比，生產版本帶來了其獨特的挑戰，我們正積極努力解決這些挑戰。下面，我們將介紹已最佳化的內容以及仍在進行中的內容。

生產最佳化

正確性

確保正確性對於可靠的生產版本至關重要。以下是目前狀態

CSS Chunking：進行中。此功能對於將 CSS 分割成更小的區塊至關重要，允許僅為應用程式的每個部分載入必要的 CSS，這有助於縮短載入時間並確保 CSS 規則的正確排序。
生產 JS Runtime：已完成。這確保 JavaScript Runtime 在生產環境中的行為符合預期，從而提供可靠性和穩定性。
基於內容的檔案名稱雜湊：尚未實作。基於內容的雜湊將允許我們根據內容產生檔案名稱，從而在瀏覽器中實現更有效率的長期快取。

UX 效能最佳化

UX 效能是提供快速載入時間和有效率的資源使用的關鍵。以下是我們正在努力的方向

JS 最小化：已完成。我們已實作 SWC Minify，自 Next.js 13 以來，Next.js 已將其與 webpack 一起使用。
CSS 最小化：已完成。使用 Lightning CSS 進行 CSS 最小化，這對於縮減樣式表的大小非常重要。
全域資訊 (整個應用程式最佳化)：已完成。Turbopack 可以套用需要應用程式中所有路由資料的最佳化，例如模組 ID 雜湊。
Tree Shaking：部分完成。進行中。我們對 tree-shaking 提供部分支援，這有助於消除未使用的程式碼並縮減捆綁包大小。但是，在某些情況下，tree-shaking 尚未完全有效
- 動態匯入：Tree shaking 對於動態匯入 (例如使用 next/dynamic) 受到限制。
- 複雜的匯出：某些類型的匯出，例如 export { foo as "string name" }。
- 非 ES 模組：CommonJS 模組無法進行 tree-shaking。
- Barrel Files：從 barrel files 重新匯出效率低下，並且在略過無副作用模組方面存在限制。
- 碎片化：在某些情況下，tree-shaking 可能會產生過多的碎片，導致捆綁包效率低下。
模組 ID 雜湊 (部分)：進行中。模組 ID 雜湊已部分實作，但我們正在努力提高效能。一旦完全啟用，它將有助於縮減最終捆綁包的大小。
匯出名稱混淆：進行中。這涉及縮減匯出名稱的大小，以縮減最終捆綁包的大小。
Scope Hoisting：尚未實作。Scope hoisting 將有助於縮減捆綁包大小，方法是將較小的 JavaScript 模組合併到單一範圍中，從而減少額外負荷並提高效能。
生產最佳化 JS Chunking：尚未實作。對 JavaScript 進行 chunking 以最小化重複項，對於提高載入效能至關重要，尤其是對於較大型的應用程式。

敬請期待

我們很高興能有信心地推薦 next dev --turbo，並且迫不及待想聽聽它如何改善您的開發體驗。立即試用看看，親身體驗效能提升。

這僅僅是開始 — 持久快取和生產版本即將到來，這將為您的工作流程帶來更快的速度和更高的可靠性。

當我們在確保正確性和最佳化效能方面取得進展，以順暢地處理即使是最大的應用程式時，我們將分享更多更新資訊。敬請期待未來的版本和改進，因為我們正努力使 Turbopack 成為開發和生產版本的最佳解決方案。

貢獻者

我們感謝成千上萬的開發人員參與 Turbopack beta 版和 release candidate 階段的測試、回報問題和驗證修正。

此版本由以下人員為您帶來

Turbopack 團隊：Alex、Benjamin、Donny、Justin、Leah、Maia、Niklas、OJ、Tim、Tobias 和 Will。
Next.js 團隊：Andrew、Hendrik、Janka、Jiachi、Jimmy、Jiwon、JJ、Josh、Sam、Sebastian、Sebbie、Shu、Wyatt 和 Zack。
Next.js 文件團隊： Delba、 Rich、 Ismael 和 Lee。