TypeScript 6.0 RC

TypeScript 6.0 RC が2026年3月に公開された。TS 5.x 系からのメジャーバージョンアップだが、目玉は新機能よりも「これまで先送りにしてきた破壊的変更を一気に入れた」点にある。6.0 は TypeScript 7.0（Go 言語で書き直したネイティブ版）への橋渡し的バージョンとして設計されており、7.0 では 6.0 で deprecated になったオプションが完全に削除される予定だ。

npm install -D typescript@rc

デフォルト設定の大幅変更

6.0 では tsconfig のデフォルト値が一気に変わる。

設定	旧デフォルト	新デフォルト
strict	false	true
module	commonjs	esnext
target	es2020	es2025
types	すべて自動列挙	[] (空)
rootDir	推論	.（カレントディレクトリ）

中でも影響が大きいのが strict: true のデフォルト化と types: [] の変更だ。strict がデフォルトで有効になることで、既存プロジェクトが型エラーだらけになるケースがある。types の変更はさらに地味に効く。これまでは node_modules/@types 以下の型定義が自動的に全部読み込まれていたが、6.0 以降は明示的に列挙しないと読み込まれない。

{
  "compilerOptions": {
    "types": ["node", "jest"]
  }
}

rootDir も要注意だ。今まで推論に任せていたプロジェクトでは、意図しない場所が rootDir として解釈される可能性がある。

廃止予定のオプション群

以下のオプションが 6.0 で deprecated になった。7.0 では削除される。

deprecated オプション	理由・代替
target: es5	ES5 ダウンコンパイルの廃止
--downlevelIteration	—
--moduleResolution node（旧 node10）	bundler または node16/nodenext を使う
--module amd / umd / systemjs / none	ESM への統一
--baseUrl	paths で代替
--moduleResolution classic	—
esModuleInterop: false / allowSyntheticDefaultImports: false	true 固定
--alwaysStrict false	strict デフォルト化に伴う
--outFile	バンドラに任せる
module キーワード（namespace の旧構文）	namespace を使う
asserts（import 属性の旧構文）	with を使う

--baseUrl の廃止は paths で代替する。

{
  "compilerOptions": {
    "paths": {
      "@app/*": ["./src/app/*"],
      "@lib/*": ["./src/lib/*"]
    }
  }
}

移行期間中は ignoreDeprecations を設定すれば、6.0 の間は deprecated オプションを使い続けられる。

{
  "compilerOptions": {
    "ignoreDeprecations": "6.0"
  }
}

ただし TypeScript 7.0 ではこのオプション自体がなくなるため、根本的な対応は避けられない。

新しい言語機能

this なし関数の型推論改善

関数が this を参照していない場合、型推論でコンテキスト感度が低くなるよう変更された。メソッド構文とアロー関数の扱いが統一される。

callIt({
  consume(y) { return y.toFixed(); },  // 以前は型エラーになるケースがあった
  produce(x: number) { return x * 2; },
});

Node.js の #/ サブパスインポート対応

{
  "imports": {
    "#": "./dist/index.js",
    "#/*": "./dist/*"
  }
}

ES2025 API の型定義追加

• RegExp.escape：正規表現用エスケープ関数
• Promise.try：同期的に投げられる例外も catch できるラッパー
• Iterator メソッド群（map、filter、take など）
• Set メソッド群（union、intersection、difference など）

Temporal API サポート

長らく Stage 3 に留まっていた Temporal 提案がついに型定義に追加された。Date オブジェクトの設計上の問題（タイムゾーン・サマータイム・カレンダー対応など）を根本から解消する API で、年単位で議論されてきたものが実際に使える形になる。

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

Map/WeakMap の upsert（getOrInsert）

ECMAScript Stage 4 に入った upsert 提案を実装。「キーが存在しなければ挿入して取得、存在すれば既存値を返す」操作が 1 行で書ける。

// 旧来の書き方
if (!map.has(key)) map.set(key, defaultValue);
const value = map.get(key);

// 6.0以降
const value = map.getOrInsert(key, defaultValue);

DOM 型の統合

これまで別 lib ファイルとして管理されていた lib.dom.iterable と lib.dom.asynciterable が lib.dom に統合された。lib の列挙から個別に指定する必要がなくなる。

--stableTypeOrdering フラグ

型 ID の割り当てが宣言順序に依存する問題を修正するためのフラグ。コードの並び替えで型チェックの結果が変わる現象を防ぐためのもので、6.0 → 7.0 の移行をスムーズにする目的もある。

CLI の変更

tsconfig.json が存在するディレクトリでコマンドラインにファイル名を渡すとエラーになるようになった。無視したい場合は --ignoreConfig を使う。

Astro プロジェクトで試してみた

このブログ（Astro 5 + TypeScript 5.9）の tsconfig.json で影響を確認した。Astro の strict プリセットを継承しているため、設定はこうなっている。

{
  "extends": "astro/tsconfigs/strict",
  "compilerOptions": {
    "baseUrl": ".",
    "paths": { "@/*": ["./src/*"] },
    "strictNullChecks": true
  }
}

Astro の strict プリセット内部で target: ESNext、module: ESNext、moduleResolution: Bundler、strict: true、esModuleInterop: true が既に設定されている。6.0 のデフォルト変更と照合すると以下のとおり。

設定	6.0 新デフォルト	このプロジェクト	影響
strict	true	true（Astro preset）	なし
module	esnext	ESNext（Astro preset）	なし
target	es2025	ESNext（Astro preset）	なし
moduleResolution	—	Bundler（Astro preset）	なし
esModuleInterop	true 固定	true（Astro preset）	なし
baseUrl	deprecated	"." を設定中	要対応

baseUrl だけ引っかかる。ただし paths を併記済みなので、baseUrl: "." の行を削除するだけで対応できる。paths のパスが ./src/* と相対パスで書かれているため、baseUrl がなくても解決先は変わらない。

@types パッケージは @types/better-sqlite3、@types/hast、@types/node の3つを使用中。6.0 で types のデフォルトが []（空）に変わるが、Astro preset 側で types を明示指定していなければ影響が出る可能性がある。ビルド時に型が見つからないエラーが出たら "types": ["node"] を追加すればいい。

ESM で統一されており require() は一切ない。CommonJS 関連の deprecated も影響なし。Astro + Vite のプロジェクトは全般的に 6.0 との相性がいい。

TypeScript 7.0 との関係

6.0 の直後に TypeScript 7.0 がリリースされる計画で、7.0 は Go 言語で書き直したネイティブ実装となる。@typescript/native-preview パッケージで現在プレビュー版を試せる。6.0 で deprecated になったオプションへの依存を今のうちに整理しておくことが、7.0 への移行コストを最小化する。プロジェクト規模が大きければ ignoreDeprecations: "6.0" で一時的に凌ぎつつ、段階的に置き換えるのが現実的な進め方だろう。