---
title: "TypeScript 6.0とは｜5から6への移行手順とts5to6・7.0との違い【6.0.3対応】"
url: "https://www.issoh.co.jp/tech/details/11066/"
published: 2026-02-19
updated: 2026-10-18
categories: ["TypeScript"]
publisher: "株式会社一創"
---

# TypeScript 6.0とは｜5から6への移行手順とts5to6・7.0との違い【6.0.3対応】

TypeScript 6.0は、JavaScriptで書かれたコンパイラとしては最後のメジャー版です。安定版の6.0.2が2026年3月23日に公開され、6.x系は2026年4月16日の6.0.3で止まっています（2026年10月時点）。npmの`latest`はすでにGo製の7.0.2です。この記事では、5.9から6.0へ上げたときに何が壊れるかを、同じコードを5.9.3・6.0.3・7.0.2で型チェックした結果で示し、ts5to6を使った移行手順と、typescript-eslintやAngularのように7.0をまだ受け付けないツールがある構成で6.0をどう残すかを整理します。

## まとめ

- 6.0は5.9と7.0をつなぐ移行用のリリースです。`strict`・`types`・`rootDir`・`target`などの既定値が変わり、`baseUrl`や`target: es5`などが非推奨エラーになります。
- `src`配下にソースを置いて`outDir`を指定し、5.9で通っていたプロジェクトを6.0.3に上げると、最初は`TS5011`（rootDir）だけが出て、それを直すと`TS2591`（types）・`TS7006`（strict）・`TS2882`（CSSのimport）が続けて出ます。
- ts5to6は`rootDir`と`baseUrl`の2つだけを書き換えるツールで、2つのフラグは同時に指定できません。`types`と`strict`は手で直します。
- 6.0でエラーなしに通るコードは、`stableTypeOrdering`を有効にし`ignoreDeprecations`を外した状態なら、7.0でもほぼ同じ結果になると公式が説明しています。
- typescript-eslint 8.71.2とAngular 22.2.3はpeerDependenciesで6.0までしか受け付けず、7.0.2と一緒に入れるとnpmが`ERESOLVE`で止まります。Vue・Svelte・Astro・MDXの言語サーバーも6.0が必要です。7.0を使うなら、`@typescript/typescript6`のエイリアスで6.0を併置します。
- 6.xに公式のサポート期限は示されていません。

## TypeScript 6.0のリリース履歴と位置づけ

6.0のベータからRC、安定版、そして7.0の安定版までの日付は、npmの公開記録で次のとおりです（日時はUTC）。

| バージョン      | npm公開日     | 区分                |
| ---------- | ---------- | ----------------- |
| 6.0.0-beta | 2026年2月11日 | ベータ               |
| 6.0.1-rc   | 2026年3月6日  | RC                |
| 6.0.2      | 2026年3月23日 | 最初の安定版            |
| 6.0.3      | 2026年4月16日 | 6.x最終（2026年10月時点） |
| 7.0.1-rc   | 2026年6月18日 | 7.0のRC            |
| 7.0.2      | 2026年7月8日  | 7.0の安定版・現在のlatest |

6.0には「6.0.0」「6.0.1」という安定版がありません。0と1はベータとRCに使われ、最初の安定版は6.0.2です。`npm install -D typescript@6`で入るのは6.0.3になります。npmに6.1は公開されておらず、`next`タグで毎日公開されている次の版は7.1.0の開発版です（2026年10月18日時点で`7.1.0-dev.20261018.1`）。

[公式の6.0発表](https://devblogs.microsoft.com/typescript/announcing-typescript-6-0/)は、6.0を「現在のJavaScriptのコードベースに基づく最後のリリース」とし、5.9と7.0の橋渡しと位置づけています。変更の大半は7.0に合わせるためのもので、コンパイラAPIは5.9と互換のままです。6.0の中身は、新機能よりも「7.0で消える設定を先にエラーにする」ことに重心があります。

## 5.9から6.0で変わる既定値と、上げた直後に出るエラー

6.0は、tsconfigに書いていない項目の既定値を一度に変えました。

| オプション                          | 5.9までの既定                          | 6.0の既定             |
| ------------------------------ | --------------------------------- | ------------------ |
| `strict`                       | false                             | true               |
| `target`                       | es5                               | es2025（その年の最新版）    |
| `module`                       | targetに依存                         | esnext             |
| `types`                        | @types配下をすべて読む                    | \[\]（何も読まない）       |
| `rootDir`                      | 共通ソースディレクトリ（composite時は設定ファイルの場所） | tsconfig.jsonのある場所 |
| `noUncheckedSideEffectImports` | false                             | true               |
| `libReplacement`               | true                              | false              |

### 5.9.3で通るプロジェクトを6.0.3にかけた結果

CSSの副作用import・型注釈のない引数・`process`の参照を含む小さなプロジェクトを、`rootDir`と`types`と`strict`を書いていないtsconfigで型チェックしました（Node.js v26.5.0・macOS・`@types/node` 24.19.2・TypeScript 5.9.3／6.0.3／7.0.2）。

```
// tsconfig.json（移行前）
{
  "compilerOptions": {
    "outDir": "dist",
    "target": "es2020",
    "module": "commonjs",
    "esModuleInterop": true,
    "skipLibCheck": true
  },
  "include": ["src"]
}

// src/index.ts（同じ階層に styles.css を置く）
import "./styles.css";
export function greet(name) {
  return `Hello, ${name} (${process.env.USER})`;
}
```

5.9.3ではエラー0件で`dist/index.js`が出力されます。6.0.3では次のように段階的にエラーが出ました。

```
$ npx tsc -p .    # 6.0.3・1回目
tsconfig.json(3,5): error TS5011: The common source directory of 'tsconfig.json' is './src'. The 'rootDir' setting must be explicitly set to this or another path to adjust your output's file layout.
  Visit https://aka.ms/ts6 for migration information.

# "rootDir": "./src" を足した2回目
src/index.ts(1,8): error TS2882: Cannot find module or type declarations for side-effect import of './styles.css'.
src/index.ts(2,23): error TS7006: Parameter 'name' implicitly has an 'any' type.
src/index.ts(3,29): error TS2591: Cannot find name 'process'. Do you need to install type definitions for node? Try `npm i --save-dev @types/node` and then add 'node' to the types field in your tsconfig.
```

1回目は`TS5011`しか表示されず、設定のエラーがある間はソースの型エラーが出ませんでした。1件直したら終わりと考えず、エラー0件になるまで繰り返し実行します。`rootDir`を直さないまま出力すると、ファイルは`dist/index.js`ではなく`dist/src/index.js`に書き出されました。7.0.2でもエラー番号と順序は同じです。

### types既定値\[\]とTS2591の直し方

`@types/node`をインストールしていても、6.0では既定でグローバル型として自動読み込みされません。`types`はこの自動読み込みを制御する設定で、importなどによる型定義の読み込みまで禁止するものではありません。`"types": ["node"]`を足すと`TS2591`は消えます。Jestを使うなら`"jest"`も並べます。[公式リリースノート](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-6-0.html)は、`types`を適切に設定しただけでビルド時間が20〜50%短くなったプロジェクトが多いと書いています。`["*"]`で5.9の自動列挙の挙動に戻せますが、不要な型パッケージの読み込みを減らす効果は得られません。20〜50%という短縮幅は公式が調べたプロジェクトの結果で、すべての構成に当てはまる保証はありません。

### strict既定trueで増えるTS7006への対処

`strict`を書いていなかったプロジェクトは、6.0で`noImplicitAny`などが一斉に有効になります。先の例では、`"strict": false`を明示すると6.0.3・7.0.2とも`TS7006`が消え、`TS2882`と`TS2591`は残りました。エラー件数が多いプロジェクトでは、いったん`false`を明示して6.0へ上げ、strictの対応は別のプルリクエストに分けるほうが差分を追いやすくなります。

CSSの副作用importで出る`TS2882`は、`declare module "*.css";`を書いた`.d.ts`を置くと消えます。`TS2882`と`TS5011`の詳しい扱いは[tsconfigのbaseUrl非推奨（TS5101）の直し方の記事](/tech/details/11519/)にまとめています。

## 6.0で非推奨になった設定・構文とエラー番号

6.0の非推奨は警告ではなくエラーとして出るため、CIの型チェックは失敗します。`"ignoreDeprecations": "6.0"`で6.0の間だけ抑止できますが、7.0ではこの指定があっても止まります。抑止の効く範囲は[baseUrl非推奨とignoreDeprecationsの記事](/tech/details/11519/)で扱っています。

| 設定・構文                                     | 6.0.3     | 7.0.2               | 移行先                        |
| ----------------------------------------- | --------- | ------------------- | -------------------------- |
| `baseUrl`                                 | TS5101    | TS5102              | pathsを相対指定                 |
| `moduleResolution: node` / `classic`      | TS5107    | TS5108              | bundler / nodenext         |
| `target: es5`                             | TS5107    | TS5108              | es2015以上                   |
| `module: amd` / `umd` / `system` / `none` | TS5107    | TS5108（noneはTS6046） | バンドラー                      |
| `outFile` / `downlevelIteration`          | TS5101    | TS5102              | バンドラー / 削除                 |
| `esModuleInterop: false`                  | TS5107    | TS5108              | 行を削除                       |
| `allowSyntheticDefaultImports: false`     | TS5107    | TS5108              | 行を削除                       |
| `alwaysStrict: false`                     | TS5107    | TS5108              | 行を削除                       |
| `module Foo {}`                           | TS1540    | TS1540              | namespace                  |
| `import ... assert {}`                    | TS2880    | TS2880              | with                       |
| tsconfigがある場所で`tsc file.ts`               | TS5112    | TS5112              | `--ignoreConfig`           |
| `/// <reference no-default-lib="true"/>`  | 無視（エラーなし） | 無視（エラーなし）           | `noLib` / `libReplacement` |

下の4行は設定ではなく書き方・呼び出し方の変更です。`import data from "./d.json" assert { type: "json" }`は6.0.3・7.0.2とも`TS2880: Import assertions have been replaced by import attributes. Use 'with' instead of 'assert'.`になりました。`TS1540`は`ignoreDeprecations`を付けても消えません。

見落としやすいのが`TS5112`です。5.9までは、tsconfig.jsonのあるディレクトリで`tsc src/index.ts`のようにファイルを指定すると、tsconfigが黙って無視されていました。6.0ではこれがエラーになり、tsconfigを無視したいときは`--ignoreConfig`を付けます。lint-stagedなどでファイルを渡して`tsc`を呼んでいるスクリプトは、ここで止まります。

逆に、エラーが出ないまま挙動が変わるのが`no-default-lib`ディレクティブです。リリースノートは「6.0ではサポートしない」とし、代わりに`--noLib`か`--libReplacement`を使うよう案内しています。この1行を先頭に書いたファイルは、5.9.3では既定のlibを読まずに`TS2318: Cannot find global type 'Array'.`などを出しましたが、6.0.3と7.0.2ではエラー0件で、既定のlibが読み込まれました。独自のlibで標準の型を差し替えていたプロジェクトは、型チェックが通ったまま別の型定義で検査されることになるため、`grep -r "no-default-lib"`で残っていないかを確かめます。

## TypeScript 5から6への移行手順

5.9から6.0.3へ上げる作業は、次の順に進めると差分が小さく保てます。最初にtsconfigを整え、最後に7.0との差を確認します。

### 手順1：5.9の既定値に依存するtsconfig項目の明示

既定値に任せていた`strict`・`target`・`module`を、5.9で動いていた値のまま明示します。`target`をes5に頼っていた場合は明示しても`TS5107`になるため、es2015以上へ上げるか、ダウンレベル変換をBabelやSWCなどの外部ツールに任せます。この段階ではまだ5.9のままで構いません。従来の実効値を明示するだけなら挙動は変わりません。ただし、es5からes2015以上へのtarget変更や外部変換ツールの導入は別の変更なので、出力と実行環境への影響を確認します。

### 手順2：ts5to6によるrootDirとbaseUrlの移行

公式リリースノートが実験的なツールとして紹介している[@andrewbranch/ts5to6](https://github.com/andrewbranch/ts5to6)（2026年10月時点で1.1.1。2025年10月7日の公開から更新はありません）は、`rootDir`を「5.9が推論していたはずの値」で書き足す機能と、`baseUrl`を消して`paths`を書き直す機能の2つを持ちます。

```
npx @andrewbranch/ts5to6 --fixRootDir .
npx @andrewbranch/ts5to6 --fixBaseUrl .
```

2つのフラグを1回で渡すと`Cannot use --fixRootDir and --fixBaseUrl together`で止まり、ファイルは書き換えられません。1つずつ実行します。先のプロジェクトに`--fixRootDir`をかけると`"rootDir": "./src"`が追加され、`TS5011`は消えました。`types`・`strict`・CSSのimportには触れないので、残りの3件は手で直します。`--fixBaseUrl`の判定の挙動は[baseUrlからpathsへの移行手順](/tech/details/11519/)で解説しています。

### 手順3：typesの列挙と6.0.3の型チェックエラー解消

6.0.3をインストールし、`types`に必要な型パッケージを並べます。先のプロジェクトは、次の設定に加えて`declare module "*.css";`だけを書いた`src/css.d.ts`を置いた状態で、6.0.3・7.0.2ともエラー0件になりました。tsconfigだけでは`TS2882`が残ります。

```
{
  "compilerOptions": {
    "outDir": "dist",
    "rootDir": "./src",
    "types": ["node"],
    "strict": false,
    "target": "es2020",
    "module": "commonjs",
    "esModuleInterop": true,
    "skipLibCheck": true
  },
  "include": ["src"]
}
```

非推奨エラーがすぐに直せない場合だけ`"ignoreDeprecations": "6.0"`を足します。7.0では効かないので、外す期限を課題として残しておきます。

### 手順4：stableTypeOrderingによる7.0との型順序の比較

型チェッカーが内部で型に振る番号の付け方が6.0と7.0で違い、宣言ファイルに出るユニオン型の順序がずれることがあります。`--stableTypeOrdering`は6.0の並び順を7.0に揃えるフラグです。公式のサンプルを3つの版で出力しました。

```
// order.ts
const x = 500;
export function foo(condition: boolean) {
  return condition ? 100 : 500;
}

// 生成された order.d.ts（--declaration --target es2022 で出力）
// 5.9.3                          : foo(condition: boolean): 500 | 100;
// 6.0.3                          : foo(condition: boolean): 500 | 100;
// 6.0.3 --stableTypeOrdering     : foo(condition: boolean): 100 | 500;
// 7.0.2                          : foo(condition: boolean): 100 | 500;
```

並び順は読み込む型の順序にも左右され、6.0.3を既定のtarget（es2025）のまま動かすとフラグなしでも`100 | 500`になりました。比べるときは6.0と7.0に同じtsconfigを渡します。宣言ファイルをコミットしている、またはスナップショットで差分を比較しているプロジェクトは、このフラグを付けた6.0と7.0で出力を比べると、並び順だけのノイズを除けます。公式は型チェックが最大25%遅くなることがあるとし、「6.0と7.0の差を診断するためのもので、常用するものではない」と明記しています。CIには常時入れません。フラグを付けて型エラーが出た場合は、型引数や変数の型注釈を明示すると解消することが多いとされています。

## TypeScript 6.0の新機能と5.9.3との型チェック結果の差

### thisを使わないメソッド構文の型推論

ジェネリック関数に渡すオブジェクトで、メソッド構文の順序によって推論が失敗する問題が直りました。

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

callIt({
  consume(y) { return y.toFixed(); },
  produce(x: number) { return x * 2; },
});
// 5.9.3（strict有効）: error TS18046: 'y' is of type 'unknown'.
// 6.0.3: エラーなし
```

メソッド構文の関数は暗黙の`this`を持つため、5.9までは型引数の推論から後回しにされていました。6.0は`this`を参照していない関数を後回しの対象から外します。アロー関数への書き換えや型注釈で回避していた箇所は、6.0では不要になります。

### #/で始まるサブパスimport

package.jsonの`imports`フィールドで、`#root/`のような名前を挟まずに`#/`だけを接頭辞にできるようになりました。`moduleResolution`が`nodenext`か`bundler`のときに使えます。

```
// package.json
{ "type": "module", "imports": { "#/*": "./dist/*" } }

// tsconfig.json
{ "compilerOptions": { "rootDir": "./src", "outDir": "dist", "module": "nodenext", "types": [] }, "include": ["src"] }

// src/index.ts
import { util } from "#/lib/util.js";
// 5.9.3: error TS2307: Cannot find module '#/lib/util.js' or its corresponding type declarations.
// 6.0.3: エラーなし（tsc後に node dist/index.js で実行できる）
```

`paths`の`@/*`と違い、Node.js自身が解決する仕組みなので、コンパイル後のJavaScriptを別名の変換なしで実行できます。そのため`imports`の参照先は出力先の`dist`に向けます。TypeScriptは`rootDir`と`outDir`の対応から`src`側の`.ts`をたどって型を解決します。参照先を`./src/*`にすると、6.0.3の型チェックは通りますが、実行時に`ERR_MODULE_NOT_FOUND`になりました。ただしNode.jsが`#/`で始まる指定を受け付けるのは25.4.0以降と24.14.0以降で、22.xと20.xの変更履歴にはこの変更が載っていません。手元のNode.js v26.5.0では、同じ構成のJavaScriptがそのまま動きました。ESMとCommonJSの解決規則の違いは[Native ESMとCommonJSの整理記事](/tech/details/12462/)を参照してください。

### es2025・Temporal・Mapのupsertに必要なlib指定

新しい標準APIの型は、入っているlibが違います。既定のtargetであるes2025に含まれるのは`RegExp.escape`までで、TemporalとMapの`getOrInsert`はesnextを指定しないと見えません。

| API                                     | 必要なlib                  | 既定のまま使うと |
| --------------------------------------- | ----------------------- | -------- |
| `RegExp.escape`                         | es2025                  | 使える      |
| `Promise.try`・Iterator・Setのメソッド         | es2025                  | 使える      |
| `Temporal`                              | esnext（esnext.temporal） | TS2304   |
| `Map.getOrInsert`・`getOrInsertComputed` | esnext                  | TS2550   |

型があっても実行環境に実装が無ければ動きません。Node.js 26の公式ビルドではTemporalが既定で有効ですが、Temporalを無効にしてビルドされたNode.js v26.5.0（Homebrew版）では、型チェックが通ったコードが実行時に`ReferenceError: Temporal is not defined`で落ちました。esnextのAPIを使うときは、動かす先のブラウザやNode.jsのバージョンで実装済みかを先に確認します。

### dom.iterableのdomへの統合と5.9.3のTS2488

`lib.dom.iterable.d.ts`と`lib.dom.asynciterable.d.ts`の中身が`lib.dom.d.ts`に取り込まれ、`"lib": ["es2020", "dom"]`のように`dom.iterable`を並べなくても、`document.querySelectorAll()`の結果を`for...of`で回せます。5.9.3では同じ設定で`TS2488`になりました。6.0.3の`lib.dom.iterable.d.ts`はライセンス表記と「互換性のために残している」という注記だけのファイルで、既存のlib指定に残っていても問題ありません。

### bundlerとcommonjsの併用と5.9.3のTS5095

`moduleResolution: bundler`を`module: commonjs`と組み合わせられるようになった変更は、非推奨になったnode10からの移行先として用意されたものです。5.9.3では同じ組み合わせが`TS5095: Option 'bundler' can only be used when 'module' is set to 'preserve' or to 'es2015' or later.`で止まり、6.0.3と7.0.2ではエラー0件でした。

## 6.0と7.0の違いと、6.0に留まる判断

7.0.2が`latest`になった今、新規プロジェクトで7.0.2を選べるのは、使うツールがすべて7.0に対応しているか、下で説明する6.0との併用が成り立つ場合です。Vue・Svelte・Astro・MDXの言語ツールと、Angular・typescript-eslintの対応範囲を先に確かめます。

| 項目             | 5.9            | 6.0            | 7.0             |
| -------------- | -------------- | -------------- | --------------- |
| 実装言語           | TypeScript（JS） | TypeScript（JS） | Go              |
| 最新版            | 5.9.3          | 6.0.3          | 7.0.2           |
| 6.0で非推奨の設定     | 使える            | エラー（抑止可）       | エラー（抑止不可）       |
| コンパイラAPI       | あり             | あり（5.9互換）      | なし（7.1で新APIの予定） |
| VS Codeのtscビルド | －              | 125.7秒         | 10.6秒           |

最終行は[7.0の公式発表](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/)に載っている、VS Codeのコードベースでの比較値です。同じ発表ではSentryが139.8秒から15.7秒、Playwrightが12.8秒から1.47秒になっています。7.0の仕組みと移行は[TypeScript 7の解説記事](/tech/details/10175/)で扱っています。

### 7.0公開後も6.0を使い続ける構成

7.0はコンパイラAPIを公開していません。このため、TypeScriptを自前の言語サービスに組み込むVolarなどのツールは6.0にしか依存できず、公式発表は「Vue・MDX・Astro・Svelteなどを使うプロジェクトは当面6.0を使い続ける必要がある」と書いています。Angularについては、通常のTypeScriptコードを検査する`tsc`には7.0、エディタには6.0を使う組み合わせを勧めています。Angularのテンプレート検査や`ng build`まで7.0へ切り替えられるという意味ではなく、Angularコンパイラには対応範囲内のTypeScriptを残します。VS Codeでは「Disable TypeScript 7 Language Server」コマンドで6.0の言語サーバーに戻せます。

### typescript-eslint・Angular・ts-jestが受け付けるTypeScriptの版

7.0へ上げられるかは、`typescript`をpeerDependenciesに持つツールの指定範囲で決まります。以下は、表に記載した各パッケージの版について、2026年10月18日に確認したTypeScriptのpeerDependenciesです。

| パッケージ（版）                       | typescriptの指定        | 6.0.3 | 7.0.2 |
| ------------------------------ | -------------------- | ----- | ----- |
| typescript-eslint（8.71.2）      | `>=4.8.4 <6.1.0`     | 可     | 不可    |
| @angular/compiler-cli（22.2.3）  | `>=6.0 <6.1`         | 可     | 不可    |
| @angular/compiler-cli（21.2.25） | `>=5.9 <6.1`         | 可     | 不可    |
| @angular/compiler-cli（20.3.34） | `>=5.8 <6.0`         | 不可    | 不可    |
| typedoc（0.28.20）               | 5.0.x〜6.0.x          | 可     | 不可    |
| svelte-check（4.7.7）            | `^5.0.0 \|\| ^6.0.0` | 可     | 不可    |
| @astrojs/check（0.9.10）         | `^5.0.0 \|\| ^6.0.0` | 可     | 不可    |
| ts-jest（29.4.15）               | `>=4.3 <7`           | 可     | 不可    |
| vue-tsc（3.3.13）                | `>=5.0.0`            | 可     | 指定上は可 |

Angular 22は6.0しか受け付けないため、Angular 22へ上げる作業は、そのまま5.9から6.0への移行になります。Angular 20のままでは6.0へ上げられません。Angular側の移行は[Angular 21の変更点と移行手順の記事](/tech/details/10025/)を参照してください。vue-tscは指定の上では7.0も入りますが、Vueの言語サーバーは先に書いたとおり6.0が前提です。

指定の外にある版を入れると、npmは依存関係の解決で止まります。npm 11.17.0で7.0.2とtypescript-eslintを一緒に入れた結果です。

```
$ npm i -D typescript@7.0.2 typescript-eslint@8.71.2 eslint@9
npm error code ERESOLVE
npm error ERESOLVE unable to resolve dependency tree
npm error Found: typescript@7.0.2
npm error Could not resolve dependency:
npm error peer typescript@">=4.8.4 <6.1.0" from typescript-eslint@8.71.2
```

`--legacy-peer-deps`で無理に入れると、インストールは通りますが、型情報を使うルールを有効にした`eslint`が`typescript-eslint does not support TS 7.0.`と表示して終了しました。メッセージは7.0の発表の併用手順と、7.1以降の対応を追う[typescript-eslintのissue #10940](https://github.com/typescript-eslint/typescript-eslint/issues/10940)を案内しています。`--legacy-peer-deps`や`--force`は解決策になりません。ESLintの設定全般は[ESLintの設定とflat configの記事](/tech/details/3286/)にまとめています。

### tsc6と7.0を併用するnpmエイリアス

typescript-eslintのように`typescript`パッケージをimportするツールだけが6.0を必要とする場合は、互換パッケージ`@typescript/typescript6`（パッケージの版は6.0.2で、中身は依存先の`typescript@^6`＝6.0.3。実行ファイル名は`tsc6`）をnpmのエイリアスで入れ、型チェックは7.0で回せます。7.0の公式発表に載っている設定です。

```
{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}
```

この構成をtypescript-eslint 8.71.2・eslint 9と一緒に入れると、npmはエラーなしで依存関係を解決しました。`npx tsc -v`は`Version 7.0.2`、`npx tsc6 -v`は`Version 6.0.3`を返し、`require("typescript").version`は`6.0.3`です。型情報を使う`@typescript-eslint/no-floating-promises`も、awaitしていないPromiseを検出しました。CIの型チェックは`tsc`（7.0）、lintは6.0のAPIという分担になります。

この構成でも7.0側は6.0の非推奨設定を受け付けません。7.0を併用する予定があるなら、`ignoreDeprecations`に頼らずtsconfigを直しておきます。コンパイラAPIに依存する自作ツールがある場合は、[TypeScript Compiler APIの記事](/tech/details/3351/)で7.0での扱いを確認してください。依存ツールの対応待ちが多い業務システムで、TypeScriptの版上げを含めて作り直す場合は、[フルスクラッチ開発](/service/system/fullscratch/)として相談を受けています。

### 6.xのサポート期限の考え方

TypeScriptには、Node.jsのLTSのような版ごとのサポート期限の公表がありません。実態としては、6.xの修正は2026年4月16日の6.0.3以降出ておらず、GitHubの`release-6.0`ブランチの最後のコミットも2026年4月15日（6.0.3への版上げ）です。6.0.3にはATA（自動型取得）のパッケージ名の検査を強化する修正が含まれていました。

周辺の目安になるのは型定義の側です。[DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped#support-window)は、公開から2年未満のTypeScriptでしか`@types`パッケージをテストしないと定めています。6.0.2の公開は2026年3月なので、2028年3月ごろには新しい`@types`が6.0で検証されなくなる計算です。7.0の公式発表は、今後も3〜4か月ごとに機能追加の版を出す方針を示しています。

6.0は長く留まる版ではありません。Vue・Svelte・Astroなどの対応を待つ間だけ6.0を使い、7.0の言語サービスが使えるようになったら切り替える前提で計画します。

## よくある質問

### TypeScript 6.0はいつリリースされましたか？

最初の安定版である6.0.2が2026年3月23日にnpmで公開されました。ベータは2026年2月11日、RCは2026年3月6日です。6.0.0と6.0.1はベータとRCに使われたため、安定版は6.0.2から始まります。6.x系の最新は2026年4月16日公開の6.0.3で、2026年10月時点で後続の修正版は出ていません。npmの`latest`はGo製の7.0.2に移っています。

### TypeScript 5と6の違いは何ですか？

言語の書き方はほぼ同じで、違いは既定値と非推奨です。6.0では`strict`がtrue、`types`が空配列、`target`がes2025に変わり、`baseUrl`や`target: es5`がエラーになります。新機能はメソッド構文の型推論改善や`#/`のサブパスimportなどで、コンパイラAPIは5.9と互換です。

### ts5to6で自動的に移行できますか？

一部だけです。`@andrewbranch/ts5to6`が自動で書き換えるのは`rootDir`の追加と`baseUrl`の削除（`paths`の書き直し）の2つで、`--fixRootDir`と`--fixBaseUrl`は同時に指定できません。`types`の列挙、`strict`で増える型エラー、`moduleResolution: node`の移行、CSSのimportで出る`TS2882`は手作業です。projectのreferencesとextendsはたどって更新します。

### TypeScript 6.0のサポート期限はいつまでですか？

公式が定めたサポート期限はありません。6.xの修正版は2026年4月16日の6.0.3が最後で、それ以降のリリースはありません。目安として、DefinitelyTypedは公開から2年未満のTypeScriptでしか型定義をテストしないため、6.0は2028年3月ごろにその範囲から外れます。Vue・Svelte・Astro・MDXなど7.0が使えない構成の中継ぎとして使い、7.0の言語サービスが対応した時点で切り替えます。

### TypeScript 6を飛ばして5.9から7.0へ直接上げてもよいですか？

できますが、推奨されません。7.0は6.0の既定値を引き継ぎ、6.0で非推奨にした設定をすべてエラーにします。`ignoreDeprecations`による一時回避もできないため、5.9から直接上げると既定値の変更と削除済み設定の修正を一度に抱えます。公式も、6.0で非推奨の指摘を解消してから7.0へ進むよう勧めています。6.0.3でエラー0件にしてから7.0.2を試すと、原因の切り分けが容易です。

## 関連記事

- [tsconfigのbaseUrl非推奨（TS5101）の直し方とignoreDeprecations・TypeScript 7.0の削除エラー](/tech/details/11519/)
- [TypeScript 7とは？Go製ネイティブコンパイラtsgoで最大10倍高速化｜RC公開と移行の要点【2026年最新】](/tech/details/10175/)
- [TypeScript Compiler APIとは｜AST解析と型情報取得の手順とTypeScript 7対応](/tech/details/3351/)
- [TypeScriptのモジュールとクラスの違い｜export/importの書き分けと7.0の変更点](/tech/details/3664/)
- [TypeScriptとは？型・型推論・型注釈の書き分けとJavaScriptとの違い【2026年版】](/tech/details/2815/)

---

出典: [TypeScript 6.0とは｜5から6への移行手順とts5to6・7.0との違い【6.0.3対応】](<https://www.issoh.co.jp/tech/details/11066/>)（株式会社一創）