TypeScript 6.0 RC：特性、重大變更及準備工作

首页 » 蟒蛇 » TypeScript 6.0 RC：特性、重大變更及準備工作

TypeScript 6.0 已正式達到發布候選版 (RC) 里程碑而且，這並非一次簡單的增量更新。這是在專案全面轉向基於 Go 語言的全新 TypeScript 7.0 引擎之前，最後一個基於長期使用的 JavaScript 編譯器和語言服務實作的主要版本。僅憑這一點，6.0 就足以成為一個關鍵版本：它是底層架構全面變革之前你必須跨越的橋樑。

您今天就可以透過 npm 安裝並試用 RC 版本。 使用：

npm install -D typescript@rc

TypeScript 6.0 的核心理念是準備和對齊此版本平滑了從 5.9 到 7.0 的過渡，收緊了默認設置，棄用了歷史遺留問題，並添加了一些針對性功能，這些功能要么反映了未來的行為，要么暴露了即將推出的 JavaScript 功能，例如 Temporal、ES2025 API 和 Map 的“upsert”方法。在此過程中，類型系統進行了一些細微的調整，新增了一些編譯器標誌和配置預設值，這些都將對實際項目產生影響——尤其是在以下方面： types, rootDir以及嚴格性。

TypeScript 6.0 作為通往基於 Go 的 7.0 版本的橋樑

TypeScript 6.0 被明確設計為現有 JavaScript 程式碼庫的最後一個主要版本。TypeScript 團隊一直在將編譯器和語言服務重寫為一個 motor nativo en Go它充分利用了原生效能和共享記憶體並行性。這個新引擎將在 TypeScript 7.0 及更高版本中首次亮相，而 6.0 則作為過渡階段緊隨其後。

6.0 版本中的大部分重大變更和棄用都是為了確保您未來能夠順利升級到 7.0 版本。無法在原生架構、舊模組系統和長期存在的怪癖中高效支援的選項，要么已被移除，要么已被明確標記為已棄用，並提供了一個退出機制：您可以設定 "ignoreDeprecations": "6.0" 在您的 tsconfig.json 可以在 6.0 版本中停用棄用診斷資訊。但該標誌在 7.0 版本中將不起作用——這些選項計劃完全移除。

如果你想在進行任何配置清理之前“等到 7.0 版本發布”，那你就掉以輕心了。6.0 RC 版本是用來修復以下問題的： tsconfig規範類型，並處理已棄用的標誌。兩次巨大的版本升級（5.x → 7.0）帶來的損失總是比分幾次升級（5.x → 6.0 → 7.0）要大得多，後者需要進行更小、更可控的更改。

自 6.0 測試版以來發生了哪些變化

在 beta 版和 RC 版之間，TypeScript 團隊主要致力於使其行為與未來的 7.0 引擎保持一致。此外，也針對類型檢查和 DOM 類型進行了一些有針對性的調整。

一項重要變更會影響傳遞給泛型呼叫的函數表達式的類型檢查。尤其是在 JSX 環境中。當使用回呼函數呼叫泛型函數時（例如在 React 或其他 JSX 元件中），RC 版本會收緊類型推斷，使其更準確地反映 7.0 版本的行為。實際上，您可能會注意到，一些依賴隱式推斷的呼叫現在需要明確提供類型參數才能通過類型檢查，但您也會發現現有程式碼中更多真正的 bug。

導入斷言語法棄用範圍也已擴大。TypeScript 已經對舊版發出警告。 import ... assert {...} 由於 ECMAScript 提案轉向使用 import 屬性，靜態導入的語法發生了變化。 with現在，這項棄用也適用於使用動態導入的情況。 import() 使用斷言對象，例如 import(..., { assert: {...}})方向很明確：到處都要導入屬性。

DOM庫類型已更新，以符合目前的Web平台標準。其中包括對 Web 環境中與時間相關的 API 的更新。如果您正在建立瀏覽器應用程序，您將受益於更精確的類型定義和圍繞這些新 API 的更完善的編輯器工具。

對於從未使用過的函數，上下文敏感性較低。 this

TypeScript 6.0 引入了一個細微但非常實用的改變，它改變了處理沒有明確賦值的函數的方式。 this 類型推斷期間的用法從歷史上看，參數缺少顯式類型的函數可以被認為是“上下文相關的”，這意味著它們的參數和 this 類型取決於它們的使用位置。這會影響泛型推斷，並可能根據函數語法導致一些奇怪的行為。

考慮一個使用生產者和消費者對的通用輔助函數。:

declare function callIt<T>(obj: {
  produce: (x: number) => T,
  consume: (y: T) => void,
}): void;

// Arrow functions: everything infers fine
callIt({
  produce: (x: number) => x * 2,
  consume: y => y.toFixed(),
});

// Flipped property order still fine with arrows
callIt({
  consume: y => y.toFixed(),
  produce: (x: number) => x * 2,
});

但是，使用方法語法時，先前的行為可能會令人驚訝。同樣的邏輯，如果寫成方法，在屬性重新排序時可能會失效，因為 TypeScript 在推斷泛型參數時會跳過「上下文相關」的函數。方法隱式地具有… this 參數，即使如此，也使他們進入了敏感類別。 this 實際上從未被提及。

在 6.0 版本中，從未讀取的函數 this 現在它們被認為對上下文的敏感度較低。換句話說，如果編譯器發現 this 如果函數內部完全沒有使用 `__init__` 屬性，則不會在推斷過程中對該函數進行懲罰。這意味著在通用推斷場景中，方法語法和箭頭語法現在更加一致，而這種奇怪的「在一種屬性順序下有效，在另一種順序下無效」的行為也會消失。

此項變更改進了類型推斷候選對象的優先排序。：沒有使用的功能 this 在推斷類型論證時，它們會成為優先順序更高的資訊來源，例如 T這種效果就沒那麼神秘了。 unknown 類型和更穩定的重構後類型推論。這項工作由 Mateusz Burzyński 貢獻。

支援 Node #/ 子路徑導入

Node 的「子路徑導入」功能允許套件透過以下方式定義內部導入別名： imports 場在 package.json這些別名透過避免使用深層相對路徑來簡化導入。以前，每個子路徑鍵在初始路徑之後都必須至少有一個段。 #對於習慣了打包器約定的人來說，這是一個雖小但令人惱火的限制，例如 @/....

TypeScript 6.0 現在支援以 `<subpath>` 開頭的子路徑導入。 #/與 Node 20 的新行為保持一致。這意味著您可以使用以下配置：

{
  "name": "my-package",
  "type": "module",
  "imports": {
    "#": "./dist/index.js",
    "#/*": "./dist/*"
  }
}

透過這種設置，套件內的模組（甚至包括使用者）都可以透過簡潔的方式匯入。 #/... 字首 而不是像這樣的長相對路徑 ../../utils.jsTypeScript 可以理解這種模式。 --moduleResolution 被設置為 node20, nodenext， 或者 bundler這與現代 Node 的語意相呼應。這項改進由貢獻者 magic-akari 實現。

使用 --moduleResolution bundler - --module commonjs

此前， --moduleResolution bundler 只能與…一起使用 --module esnext or preserve隨著舊版的棄用， node/node10 在模組解析模式下，許多專案需要一個適合其目前 CommonJS 輸出的遷移路徑。

TypeScript 6.0 現在允許合併 --moduleResolution bundler - --module commonjs這種組合通常是程式碼庫仍在產生 CommonJS 程式碼，但正在向以打包工具為中心的工作流程或更新的解析邏輯過渡的實用過渡方案。在此基礎上，專案可以規劃長期遷移到以下兩種方案之一：

• module: "preserve" - moduleResolution: "bundler" 對於捆綁式 Web 應用程式和類似設置，或者
• module: "nodenext" 適用於直接面向現代 Node.js 的環境。

這項變化對離開的團隊尤其重要。 moduleResolution: node 背後 但我還沒準備好完全接受ESM的輸出。它提供的是一條分階段的道路，而不是一條懸崖。

这 --stableTypeOrdering 標記以模擬 7.0 排序

TypeScript 7.0 的主要架構升級之一是並行類型檢查。並行運行多個檢查器意味著程式的不同部分可以以不同的順序存取。如果類型 ID 和符號順序取決於存取順序，則最終可能導致聯合體順序、屬性順序不確定，甚至診斷結果出現罕見的差異。

舊版的 TypeScript 會根據類型出現的順序指派內部類型 ID。這些 ID 隨後用於對聯合類型和屬性等內容進行排序。這就是為什麼看似無害的編輯——例如引入一個新的 ID——可能會造成嚴重後果。 const 在現有函數之前－可以翻轉已發出函數中字面聯合的順序。 .d.ts 文件，或更改編輯器中某些類型的列印方式。

TypeScript 7.0 將內部物件的排序方式改為確定性的、基於內容的排序。每個類型或符號都根據其結構進行排序，而不是根據存取順序，因此同一個程式無論並行處理還是編譯順序如何，都會始終產生相同的排序結果。這就消除了「為什麼我的聯合體順序突然顛倒了？」的謎團。

為了幫助您比較 6.0 和 7.0 之間的行為，RC 引入了 --stableTypeOrdering啟用此標誌後，TypeScript 6.0 將採用與 7.0 相同的確定性類型排序演算法。其結果是產生的聲明文件中差異大大減少，並且 6.x 和 7.x 輸出之間的比較結果更具可預測性。

然而，決定論並非自由的。。啟用 --stableTypeOrdering 根據程式碼庫的不同，類型檢查可能會使速度降低約 25%。它旨在輔助診斷和遷移，而不是永久啟用的效能最佳化設定。

如果您只在以下情況下看到類型錯誤 --stableTypeOrdering 已開啟這通常意味著你之前的程式碼依賴舊的、近乎偶然的類型順序來進行類型推斷，使其「正常工作」。修復方法通常涉及明確地定義類型——例如，在有問題的泛型呼叫中添加類型參數，或使用特定的介面註解變量，而不是完全依賴類型推斷來處理複雜物件。

New es2025 目標和庫選項

TypeScript 6.0 新增了一個 es2025 兩者皆可 target 以及 lib雖然 ES2025 相較於前幾年並沒有引入新的核心語法，但它確實整合了幾個先前需要透過其他技術才能實現的標準化 API。 esnext.

透過有針對性或包含 es2025您將獲得新內建函數的更新類型定義 点讚 RegExp.escape並且一些 API 被移出了… esnext 加到 es2025這包括以下方面： Promise.try迭代器助手和其他 Set 已達到完全規範成熟度的方法。這項工作由森內健太（Kenta Moriuchi）貢獻。

更廣泛地說，預設設定是… target 6.0 版本現在會追蹤目前的 ECMAScript 年份。目前，如果不指定目標版本，實際上會預設使用 ES2025。這更符合常青運行時和現代工具的實際情況。

時間 API 的內建類型

備受期待的「時間」提案已進入第三階段，預計將取代臭名昭著的… Date 用於嚴肅的日期/時間工作的 APITypeScript 6.0 現在為 Temporal 提供了一流的類型定義，因此您可以開始編寫基於 Temporal 的程式碼，並獲得完整的類型安全性和編輯器支援。

若要啟用時間類型，您可以使用 --target esnext 或明確配置你的庫。 例如：

{
  "compilerOptions": {
    "lib": 
  }
}

或者您可以選擇僅使用時間子集。 "esnext.temporal" 如果您需要更精細的配置，啟用後，您可以編寫類似這樣的程式碼：

let yesterday = Temporal.Now.instant().subtract({
  hours: 24,
});

let tomorrow = Temporal.Now.instant().add({
  hours: 24,
});

console.log(`Yesterday: ${yesterday}`);
console.log(`Tomorrow: ${tomorrow}`);

某些運行時環境已經支援 Temporal，而其他運行時環境則可以透過 polyfill 來實現 Temporal。因此，這些類型現在確實可用。 MDN 上正在逐步完善相關文件（但仍有一些空白需要補充）。這些類型定義由 GitHub 使用者 Renegade334 貢獻。

Upsert 支援： Map.getOrInsert 以及 getOrInsertComputed

JavaScript 開發人員一直在手動編寫「檢查-然後設定-然後取得」模式 Map 多年一個典型的模式是檢查鍵是否存在，如果不存在則設定預設值，最後回傳一個值——這種樣板程式碼很容易出錯或在很多地方重複出現。

ECMAScript「upsert」提案（現為第4階段）引進了 getOrInsert 以及 getOrInsertComputed on Map 以及 WeakMapTypeScript 6.0 為這些方法新增了類型支援。 esnext lib，因此您可以立即開始編寫更多聲明式 upsert 操作。

與 getOrInsert像這樣冗長的模式:

function processOptions(compilerOptions: Map<string, unknown>) {
  let strictValue: unknown;
  if (compilerOptions.has("strict")) {
    strictValue = compilerOptions.get("strict");
  } else {
    strictValue = true;
    compilerOptions.set("strict", strictValue);
  }
  // ...
}

可以折疊成單行:

function processOptions(compilerOptions: Map<string, unknown>) {
  let strictValue = compilerOptions.getOrInsert("strict", true);
  // ...
}

同伴 getOrInsertComputed 非常適合高額違約金它接受一個回調函數，該函數僅在鍵缺失時才會被呼叫。這個回調函數甚至可以接收鍵作為參數，從而允許你從鍵本身推導出預設值。 TypeScript 的類型定義精確地描述了這些行為，這再次要感謝 Renegade334 的貢獻。

RegExp.escape 以及更安全的正規表示式構建

如果你曾經將使用者提供的字串拼接成正規表示式，你就知道應該先對特殊字元進行轉義。但大多數程式碼庫要么在輔助函數中重新實現轉義，要么完全忽略它。正規表示式轉義提案（目前處於第四階段）對此進行了標準化。 RegExp.escape.

TypeScript 6.0 公開了以下類型： RegExp.escape 在 es2025 LIB這意味著，當您以 ES2025 為目標或包含 ES2025 時，您可以安全地編寫以下輔助函數：

function matchWholeWord(word: string, text: string) {
  const escapedWord = RegExp.escape(word);
  const regex = new RegExp(`\\b${escapedWord}\\b`, "g");
  return text.match(regex);
}

不再需要手動編寫的退出函數了這樣，TypeScript 將能夠完全理解並進行類型檢查。這項新增功能與 ES2025 目標的工作一樣，都出自 Kenta Moriuchi 之手。

dom lib 現在包含了迭代和非同步迭代 API

從歷史上看，TypeScript 將 DOM 迭代器支援拆分為 dom, dom.iterable以及 dom.asynciterable如果你想遍歷 NodeList or HTMLCollection - for...of你必須記得加上 dom.iterable 在您的 "lib" 配置旁邊 dom這曾經是一個常見的困惑來源，尤其是所有現代瀏覽器都支援 DOM 集合上的可迭代物件和非同步可迭代物件。

在 TypeScript 6.0 中， lib.dom.iterable.d.ts 以及 lib.dom.asynciterable.d.ts 有效地合併 lib.dom.d.ts這意味著使用 "dom" 預設情況下，aonly 會提供可迭代和非同步迭代的行為。

你仍然可以提及 dom.iterable 以及 dom.asynciterable 在您的 tsconfig但是這些檔案現在都是空的 shell 檔。如果您先前的配置如下所示：

{
  "compilerOptions": {
    "lib": 
  }
}

您可以安全地將其簡化為僅 "dom"以及 DOM 集合的迭代，例如 document.querySelectorAll("div") 仍會進行類型檢查：

for (const element of document.querySelectorAll("div")) {
  console.log(element.textContent);
}

這是一次雖小但值得歡迎的清理工作 這樣就使預設的 DOM 庫與當前瀏覽器的實際情況保持一致，並消除了專案設定中的另一個陷阱。

TypeScript 6.0 中的預設值、棄用項目和重大變更

除了酷炫的 API 之外，6.0 版本還對 TypeScript 的預設設定進行了一些自 1.0 版本以來最具前瞻性的更改。這些變化反映了目前的 JavaScript 生態系統：常青運行時間、以 ESM 為基礎、廣泛使用打包器，以及對嚴格類型和效能的強烈需求。

該團隊重點闡述了支撐這些決策的幾個總體趨勢。ES5 和真正的傳統瀏覽器幾乎已經消失；AMD/UMD 模組系統是小眾產品；現在幾乎所有東西都是以模組形式發布的；嚴格的類型是常態；性能必須始終放在首位，尤其是在 7.0 引入並行檢查的情況下。

因此，TypeScript 6.0 和 7.0 正在採用更現代化的預設設置，並減少「舊式退出機制」。對於 6.0 RC 版本，您可以透過設定來暫時停用棄用提示。 "ignoreDeprecations": "6.0" 在您的 tsconfig但這些選項在 7.0 版本中將不再存在。一些調整可以透過類似實驗性工具的工具實現自動化。 ts5to6 程式碼轉換可以幫助重寫諸如…之類的程式碼 baseUrl 以及 rootDir 項目內的各種配置。

兩項調整，許多項目都需要立即進行。

雖然棄用清單很長，但其中兩個設定變更可能會對最多的程式碼庫造成影響。:

• 明確設定 types 排列 （經常） （加上你的測試框架）。如果沒有這個，你將會遺失自動包含的環境類型。 @types/*.
• 明確設定 rootDir （通常 "./src") 如果你依賴的是舊的「通用根目錄推論」方法，那麼你產生的檔案結構可能會發生細微的變化。

缺失症狀 types 包括大量關於全域變數的錯誤，例如 process, fs, path， 或者 describe 未定義變化的症狀 rootDir 更多的是關於輸出路徑意外地獲得額外收益。 src 片段（例如） dist/src/index.js 而不是 dist/index.js).

針對現代專案更新的預設設定

現在，多個編譯器選項有了新的預設值，這些值與大多數新應用程式的實際建置方式相符。:

• strict 現在預設為 true嚴格模式不再是可選項，而是預設設定。如果您之前依賴非嚴格模式，則需要明確設定。 "strict": false （雖然這樣你會錯過很多安全檢查項目）。
• module 現在預設為 esnext這反映出 ESM 是主流的模組格式，並且與打包工具和現代 Node 相容性最好。
• target 預設使用目前的 ECMAScript 版本（目前實際上是 ES2025）。承認大多數部署都針對常青環境，或透過打包程序，在真正需要時可以進一步降級。
• noUncheckedSideEffectImports 現在是 true 默認情況下，幫助您發現僅為產生副作用而匯入的文件中的拼字錯誤或錯誤路徑。
• libReplacement 默認為 false這樣就避免了大量額外的模組解析失敗和監視開銷，直到專案明確選擇使用專門的庫行為。

如果這些新的預設設定中有任何一項破壞了您的構建，它們都可以在以下程式碼中明確地被覆蓋： tsconfig.json但其目的是讓新項目「無需額外配置即可自動執行正確的操作」。

rootDir 現在預設使用配置目錄

以前，如果您沒有指定 rootDirTypeScript 嘗試推斷一個共同的源根 基於程式中所有非聲明文件。這使得確定專案邊界變得更加困難，並且需要掃描大量檔案路徑才能確定 emit 的根目錄。

在 TypeScript 6.0 中，預設值 rootDir 就是包含以下內容的目錄 tsconfig.json舊的推理行為僅適用於您運行 tsc 在命令列上沒有任何 tsconfig 在所有。

這項變更意味著，來源檔案位於 config 目錄下的項目應該明確設置 rootDir常見的配置如下：

{
  "compilerOptions": {
    // ...
    "rootDir": "./src"
  },
  "include": 
}

如果您的設定引用了上述文件， tsconfig 位置方面，你還需要擴展 rootDir 從而，例如 "rootDir": "../src" 用於共享來源目錄。

types 現在預設值為空數組

這可以說是對實際專案影響最大的變化。從歷史上看，如果你沒有明確說明… types in compilerOptionsTypeScript 會自動包含以下所有內容 node_modules/@types這很方便，但也成本高昂且不穩定：現代程式碼庫通常會引入數百個… @types 傳遞包裹。

在 TypeScript 6.0 中， types 默認為 []這意味著不會自動載入任何環境類型包。現在，您可以明確選擇加入實際需要的全域環境，例如：

{
  "compilerOptions": {
    "types": 
  }
}

在某些專案中，這可以縮短 20% 到 50% 的建置時間。因為編譯器不再需要遍歷每個聲明檔。 @types如果您確實想要恢復先前的「載入所有內容」的行為，您可以指定：

{
  "compilerOptions": {
    "types": 
  }
}

如果您突然看到類似「找不到名稱『process』」或「找不到模組『fs』」的錯誤這是你添加的提示 node （以及您依賴的任何其他測試/運行時類型）到您的 types 數組。

棄用： target: es5 以及 --downlevelIteration

現在已棄用 ES5 版本。鑑於所有主流瀏覽器多年來都已支援 ES2015 及以上版本，且 Internet Explorer 也已停止維護，TypeScript 內部實現 ES5 輸出的複雜性已不再值得。未來 TypeScript 支援的最低目標版本為 ES2015。如果您確實需要使用 ES5，建議您在 TypeScript 原始碼或輸出中使用外部轉譯器（例如 Babel 或打包工具）。

这 --downlevelIteration 標誌也已棄用因為它的唯一有意義的用例是調整 ES5 目標的 emit 行為。在 TypeScript 6.0 中，設定 downlevelIteration 這樣做會產生棄用錯誤。如果您使用的是 ES2015 或更高版本，那麼該標誌本來就沒有任何作用。

棄用： --moduleResolution node 和遺產 classic

这 node （又名 node10模組解析模式已棄用它模擬了 Node 10 的行為，但與現代 Node 的 ESM 和解析語意不符。專案應該遷移到以下任一版本： nodenext （針對直接節點目標）或 bundler （適用於像 Web 應用程式或 Bun 這樣的打包工具驅動的環境）。

原 moduleResolution: classic 該策略也已被移除。這是 TypeScript 在 Node 解析之前的故事。如今，所有實際場景都由以下方式更好地滿足需求： nodenext or bundler因此，經典模式被淘汰，以減少複雜性和極端情況。

已棄用：AMD、UMD、SystemJS 和 module: none

下面 module 這些值現已棄用，並且實際上不再受支援。:

• amd
• umd
• systemjs
• none

這些格式在ESM時代之前至關重要。過去，瀏覽器缺乏原生模組支持，開發者只能依靠 AMD、UMD 或 SystemJS 來彌補這一不足。如今，ESM 加上打包工具或導入映射幾乎可以滿足所有實際應用場景，「無」這個概念也從未有過明確的定義。

如果您仍然以這些舊版模組格式為目標，請繼續閱讀。因此，建議遷移到支援 ESM 的目標平台，並依賴打包工具或其他編譯器進行最終打包——或繼續使用 TypeScript 5.x，直到製定好遷移計劃。作為清理工作的一部分，舊的 amd-module 指令也被刪除。

棄用： baseUrl

这 baseUrl 長期以來，該選項一直是導致模組解析行為異常且難以調試的原因之一。許多項目僅將其用作前綴。 paths 條目，但 TypeScript 也將其視為通用查找根，導致類似這樣的導入： "someModule" 決心 src/someModule.js 出乎意料的是，開發者原本只是想支援自訂別名，例如 @app/*.

在6.0， baseUrl 已棄用，將不再用作查找根。路徑映射不需要 baseUrl 這種情況已經持續相當長一段時間了，因此建議的遷移方法是將前綴合併到每個中。 paths 輸入。例如：

// Before
{
  "compilerOptions": {
    "baseUrl": "./src",
    "paths": {
      "@app/*": ,
      "@lib/*": 
    }
  }
}

// After
{
  "compilerOptions": {
    "paths": {
      "@app/*": ,
      "@lib/*": 
    }
  }
}

只有在極少數情況下，你才會真正使用 baseUrl 作為通用查找根 您是否需要使用類似這樣的通用路徑映射來重現該行為：

"paths": {
  "*": ,
  "@app/*": ,
  "@lib/*": 
}

對於大多數團隊來說，只需移除 baseUrl 以及內聯前綴 paths 會更清晰、更安全.

互通性和嚴格性： esModuleInterop, allowSyntheticDefaultImports以及 alwaysStrict

TypeScript 6.0 也鎖定了長期以來推薦的預設互通行為。您將無法再進行設置 esModuleInterop or allowSyntheticDefaultImports 至 false這些選項最初是可選的，以避免破壞舊項目，但如今禁用它們通常會導致在混合使用 CommonJS 和 ESM 時出現一些不易察覺的運行時問題。

如果始終啟用互通性，則可能需要更新某些匯入模式。。 例如：

// Old style with esModuleInterop: false
import * as express from "express";

// New style with modern interop always on
import express from "express";

这 alwaysStrict 標誌也不能設定為 false 再TypeScript 現在全面採用 JavaScript 嚴格模式語義，包括保留字和 this 行為規範。如果您有使用保留字的非常古老的程式碼，例如 await or static 作為標識符，您需要重新命名它們。

棄用： outFile舊版命名空間 module 關鍵字，並導入 asserts

这 --outFile 6.0 版本中移除了該選項。將多個輸入合併成一個 JS 套件，這項工作更適合由 Webpack、Rollup、esbuild、Vite、Parcel 或類似工具來完成。 TypeScript 更專注於類型檢查和聲明輸出，而不是試圖成為一個打包工具。

傳統用途 module 聲明命名空間現在是一個硬性錯誤。早期 TypeScript 允許：

module Foo {
  export const bar = 10;
}

現代的、受支援的語法使用 namespace:

namespace Foo {
  export const bar = 10;
}

此項變更是必要的，旨在避免與未來可能出現的 ECMAScript 衝突。 module 塊環境模組聲明，例如 declare module "some-module" { ... } 將繼續獲得全力支持。

使用導入斷言 asserts 也已棄用因為底層提案演變成了使用導入屬性。 with類似這樣的程式碼：

import blob from "./data.json" asserts { type: "json" };

應遷移到新表單:

import blob from "./data.json" with { type: "json" };

棄用： no-default-lib 使用 tsconfig 查看參考資料和命令列文件列表

这 /// <reference no-default-lib="true" /> 該指令已不再受支援。它經常被誤解。如果您需要排除預設庫，請使用 --noLib or --libReplacement 相反，它在配置層面上更清晰地表達了意圖。

另一個長期存在的困惑點在於如何 tsc 處理顯式檔案參數時 tsconfig.json 存在此前，運行 tsc foo.ts 如果將設定檔放在這樣的目錄中，系統會靜默忽略該設定檔。在 6.0 版本中，這種情況會產生明確的錯誤：

error TS5112: tsconfig.json is present but will not be loaded if files are specified on commandline. Use '--ignoreConfig' to skip this error.

如果你真的想繞過配置，只編譯一個包含預設值的單一文件現在你可以使用 tsc --ignoreConfig foo.ts 為了明確表達這項意圖。

準備迎接 TypeScript 7.0

TypeScript 6.0 功能已全部實現，目前基本上處於穩定模式。從現在到正式發布，團隊預計只會修復一些關鍵 bug。他們會定期發布每日建置版本，同時也會發布即將推出的原生（基於 Go 語言）TypeScript 7.0 的每日建置版本，以及一個專門用於體驗新引擎的 VS Code 擴充功能。

路線圖刻意安排得非常緊湊：預計 7.0 版本將在 6.0 版本之後不久發布。因此，關於升級難題和遷移問題的回饋週期將會很短。如果您在 6.0 版本中看到棄用警告，強烈建議您現在就解決這些問題，而不是等到 7.0 版本強制出現這些問題。

大多數團隊的實際工作流程大致如下升級到 TypeScript 6.0 RC，修復你的問題 types 以及 rootDir解決棄用問題（或暫時將其隱藏起來）。 "ignoreDeprecations": "6.0" （當你迭代時），並運行 --stableTypeOrdering 如果您需要比較輸出結果或為 7.0 版本的確定性排序準備 CI 管線，那麼一旦完成這些設置，遷移到基於 Go 的編譯器應該感覺像是一次效能升級，而不是一次破壞性的重寫。

總而言之，TypeScript 6.0 RC 的重點不在於華麗的文法，而是搭建舞台。7.0 版本擁有原生速度、更簡潔的配置、現代化的預設設置，以及 Temporal 和 ES2025 內建函數等標準化 API，讓日常編碼更加輕鬆。如果您現在就採用新版本，修復一些冗餘程式碼，並充分利用新的預設設置，那麼在原生編譯器正式發佈時，您將處於更有利的地位。