tsconfigのbaseUrl非推奨（TS5101）の直し方とignoreDeprecations・TypeScript 7.0の削除エラー

TypeScript 6.0に上げると、tscがerror TS5101: Option 'baseUrl' is deprecatedを出して非ゼロの終了コードで止まります。"ignoreDeprecations": "6.0"で6.0の間は黙らせられますが、7.0では同じ設定がTS5102（削除済み）に変わり、抑止の手段がありません。2026年10月20日に出た7.1 Betaでも同じです。この記事は、baseUrlを消してpathsへ移す手順と、消したあとに実行時・テスト・ビルドツールで別名が解決できなくなる箇所の直し方を、typescript 5.9.3・6.0.3・7.0.2・7.1.0-betaの実際の出力で説明します。

まとめ

• baseUrlは6.0で非推奨（TS5101）、7.0で削除（TS5102）。"ignoreDeprecations": "6.0"は6.0でしか効かず、7.0.2と7.1 Betaでは付けたままでも同じエラーで止まる。
• 恒久対処はbaseUrlを消し、pathsの各値を./始まりの相対パスに書き直すこと。./を付け忘れるとTS5090になる。import "lib/util"のような接頭辞なしの書き方をしていたら"*": ["./src/*"]も要る。
• 5.9以前のTypeScriptで"ignoreDeprecations": "6.0"を書くとTS5103: Invalid valueになる。エディタとnode_modulesの版がずれていないか先に確かめる。
• pathsは型チェック用の設定で、出力JavaScriptのimportは書き換わらない。tsconfig-pathsをTS_NODE_BASEURL=./distで使っていた構成は、pathsを./src/*のように出力先と違うディレクトリ込みで書き直すと、実行時にCannot find moduleで落ちる。
• 自分のtsconfigにbaseUrlが無いのにTS5101が出るなら、extendsしたプリセット、ビルドツールが渡す設定（tsup 8.5.1以前の型定義生成など）、コマンドラインの--baseUrlを疑う。tsupは9.0.0で直った。

設定変更後は、型チェック・実行・テストをそれぞれ確認してください。TypeScript 6.0の新機能やリリースの位置づけはTypeScript 6.0の総まとめ記事にまとめています。

6.0と7.0で出るエラー番号の対応表

6.0の非推奨は「警告」ではなくerrorとして出ます。macOS・Node.js v26.5.0での検証では、終了コードは6.0.3で2、7.0.2で1、7.1.0-betaで2でした。CIでは「非ゼロなら失敗」と判定しておけば版をまたいでも外れません。noEmitOnErrorが既定のfalseなら6.0.3は出力ファイルを書き出すため、ローカルのビルドだけ見ていると通ったように見えることがあります。

TS5101はオプションそのものの非推奨、TS5107は「オプション＝特定の値」の非推奨です。直し方は同じで、該当行を消すか値を変えます。7.0.2と7.1.0-betaのbaseUrlとmoduleResolution: nodeの番号・文面は同じでした（7.1 Betaのリリースは2026年10月20日公開で、npmのbetaタグ）。日本語ロケールの6.0では、次のメッセージが表示されます。

error TS5101: オプション 'baseUrl' は非推奨であり、TypeScript 7.0 で機能しなくなります。compilerOption '"ignoreDeprecations": "6.0"' を指定して、このエラーを無音にします。
  移行情報については、http://aka.ms/ts6 にアクセスしてください。

構文レベルでも2つ変わっています。名前空間をmodule Foo {}と書くとTS1540、import data from "./d.json" assert { type: "json" }はTS2880（assertをwithへ）です。TS1540はignoreDeprecationsを付けても消えないため、namespaceへ書き換えるしかありません。

baseUrlを削除してpathsへ移す手順

baseUrlには「pathsの基準ディレクトリ」と「モジュール探索のルート」という2つの役割がありました。6.0の公式リリースノートは後者を問題視しており、baseUrlが./srcならimport "someModule.js"が意図せずsrc/someModule.jsに解決されてしまう例を挙げています。どちらの役割に頼っていたかで、書き換え方が変わります。

pathsの接頭辞にだけ使っていたときの書き換え

公式が「ほとんどのプロジェクトはこちら」としているケースです。baseUrlの値をpathsの各値の先頭へ移し、baseUrlの行を消します。

// 変更前
{
  "compilerOptions": {
    "baseUrl": "./src",
    "paths": { "@/*": ["*"] }
  }
}

// 変更後
{
  "compilerOptions": {
    "paths": { "@/*": ["./src/*"] }
  }
}

baseUrlが無い状態のpathsは、そのtsconfig.jsonがあるディレクトリを基準に解決されます。baseUrl: "."だった場合は、各値の頭に./を付けるだけで同じ意味になります。この構成は5.9.3から7.1.0-betaまでの4版すべてでエラー0件でした。

baseUrlを探索ルートにしていたときの「*」マッピング

import { add } from "lib/util"のように、@/などの接頭辞なしでsrc配下を指していたコードがある場合です。前節の書き換えだけで済ませると、6.0.3でも7.0.2でもerror TS2307: Cannot find module 'lib/util'になります。受け皿として"*"を1行足します。

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

"*"は、接頭辞なしのimportをすべて先にsrcから探させる設定です。src/react.tsのようなファイルがあればnpmパッケージより優先されるので、長く残すより@/lib/utilへ置換して"*"を外すほうが事故は減ります。

「./」の付け忘れで出るTS5090

baseUrlを消して"@/*": ["src/*"]のまま残すと、6.0.3はTS5090: Non-relative paths are not allowed when 'baseUrl' is not set. Did you forget a leading './'?を出します。7.0.2と7.1 BetaではbaseUrlを残したままでも、TS5102と並んでTS5090が出ます。値の先頭に./を付ければ解消します。

ts5to6でbaseUrlとrootDirの書き換えを自動化する手順

6.0のリリースノートが「実験的なツール」として紹介している@andrewbranch/ts5to6（1.1.1）は、baseUrlの削除とrootDirの明示の2つだけを自動で行うツールです。referencesを再帰的にたどり、extendsで影響を受ける設定ファイルも更新対象にします。

npx @andrewbranch/ts5to6 --fixBaseUrl .
npx @andrewbranch/ts5to6 --fixRootDir .
# tsconfig.json以外の名前なら設定ファイルを直接指定
npx @andrewbranch/ts5to6 --fixBaseUrl ./tsconfig.app.json

このツールの利点は、前章の2つのケースを見分けることです。baseUrl: "./src"でimport "lib/util"を含むプロジェクトに--fixBaseUrlをかけると、「1 project rely on baseUrl for module resolution」と表示し、pathsを./src/*へ付け替えたうえで"*": ["./src/*"]を追加しました。接頭辞付きのimportしか無いプロジェクトでは「No projects rely on baseUrl for module resolution」と出て、"*"は足さずにpathsを相対指定へ直すだけでした。

書き換え対象はbaseUrlとrootDirに限られます。moduleResolution: nodeは変更前のまま残り、その状態で7.0.2にかけるとTS5108が出ました。--fixBaseUrlと--fixRootDirは同時に指定できないので、2回に分けて実行します。

"ignoreDeprecations": "6.0"の効く範囲と7.0で効かなくなる点

"ignoreDeprecations": "6.0"をcompilerOptionsに足すと、6.0.3ではTS5101とTS5107が消え、baseUrlは探索ルートとしても従来どおり働きます。リリースノートの本文は「探索ルートとして扱わなくなる」と書いていますが、6.0.3でこの指定を付けた場合はimport "lib/util"がそのまま解決されました。移行を先送りしても挙動は変わりません。

受け付ける値は版ごとに違います。baseUrlを消した正常な設定にignoreDeprecationsだけを足して、4版で試した結果です。

7.0.2と7.1 Betaは"6.0"も"7.0"も値としては受け付けますが、削除済みオプションのエラーは消しません。7.0の公式発表も、6.0で非推奨にしたフラグは7.0でハードエラーにすると明記しています。moduleキーワードの名前空間（TS1540）は6.0でも抑止できません。

ignoreDeprecationsは、6.0に上げた日にCIを通すための一時的な措置です。入れるなら外す期限を課題管理に残しておかないと、7.0へ上げる日にまとめて噴き出します。7.0の全体像や移行の段取りはTypeScript 7の解説記事で扱っています。

TS5103「Invalid value for ‘–ignoreDeprecations’」が出る原因

Next.jsのビルドでType error: Invalid value for '--ignoreDeprecations'.と出る、あるいはtscがTS5103を出す場合、実際に動いているTypeScriptが設定より古いことがほとんどです。5.9.3は"6.0"を知らないので、記事やエディタの指示どおり"6.0"を書いた時点でTS5103になります。エディタが新しいTypeScriptで非推奨を表示している一方、プロジェクトのnode_modulesは5.9のまま、というずれで起きやすい組み合わせです。

npx tsc -v
npm ls typescript

表示が5.x なら、ignoreDeprecationsの行を消すか、typescriptを6.0以上に上げます。モノレポで6.0と5.9が混在している場合は、共通のtsconfigに"6.0"を書くと5.9側のパッケージが落ちるため、baseUrl自体を消すほうが確実です。baseUrlを使わないpathsの書き方は5.9でも通ります。

7.0へ上げられないときの@typescript/typescript6の併用

7.0.2（2026年7月8日公開、npmのlatest）は、従来のTypeScript Compiler APIを同梱していません。typescript-eslintやtsupのようにtypescriptパッケージをimportするツールが残るなら、6.0のAPIを再公開する互換パッケージ@typescript/typescript6（実行ファイル名はtsc6）をnpmエイリアスで入れ、型チェックだけ7.0のtscで回す構成が公式に案内されています。この構成でtsc -vは7.0.2、tsc6 -vは6.0.3を返しました。7.0側は非推奨オプションを受け付けないので、tsconfigは先に直しておく必要があります。

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

社内に同じ構成のリポジトリが多数あり、ツールの対応状況を見ながら6.0と7.0への移行を段階的に進める場合は、システムマイグレーション・リプレイスとして計画から引き受けています。

baseUrlを消したあと実行時とテストで別名を解決する設定

pathsは型チェックのための設定で、tscは出力JavaScriptのimport文字列を書き換えません。"@/*": ["./src/*"]でコンパイルしたCommonJS出力はrequire("@/lib/util")のままで、node dist/index.jsはError: Cannot find module '@/lib/util'で落ちました。baseUrlを消す作業は、実行時に別名を解決していた仕組みにも影響します。

tsconfig-pathsでdistを実行していた構成の直し方

tsconfig-paths 4.2.0で、baseUrlを消したtsconfigのままnode -r tsconfig-paths/register dist/index.jsを実行すると、@/lib/utilはsrc配下（.tsファイル）を指して解決できませんでした。以前よく使われたTS_NODE_BASEURL=./distも効きません。pathsの値が./src/*のように基準ディレクトリ込みで書かれているため、dist/src/...を探してしまうからです。

実行時用の小さな設定ファイルを分け、TS_NODE_PROJECTで渡すと動きました。このファイルはtscには読ませません。

// tsconfig.runtime.json（tsconfig-paths専用）
{ "compilerOptions": { "paths": { "@/*": ["./dist/*"] } } }

保存後、プロジェクトのルートで次のコマンドを実行します。

TS_NODE_PROJECT=tsconfig.runtime.json node -r tsconfig-paths/register dist/index.js

tsconfig-pathsは4.0.0でbaseUrlの無い設定に対応しています。3.x系を使っているなら先に4系へ上げてください。新規に組むなら、Node.jsのpackage.jsonのimports（#app/utilなど、#で始まる別名）を使えば、実行時もTypeScriptも同じ定義を読むので、この二重管理が要りません。

tsx・Vite・Jestでの確認結果

pathsを{"@/*": ["./src/*"]}にしてbaseUrlを消した同じプロジェクトを、各ツールで動かした結果です（TypeScript 6.0.3）。

Jestはtsconfigのpathsを読まないので、moduleNameMapperが無いとCannot find module '@/lib/util'で失敗します。ts-jestのpathsToModuleNameMapperにprefix: "<rootDir>/"を渡すと、./src/*の./は落とされて{"^@/(.*)$": "<rootDir>/src/$1"}が生成され、テストは通りました。Viteはresolve.tsconfigPathsをtrueにした状態で確認しています。Vite 8の設定全体はVite + Reactの環境構築記事を参照してください。

moduleResolution node（node10）非推奨の移行先

moduleResolution: nodeはNode.js 10時点の解決規則を固定したもので、6.0ではnode10として非推奨になりました。公式の案内は「Node.jsで直接動かすならnodenext、バンドラーやBunを使うならbundler」です。7.0.2と7.1 BetaではOption 'moduleResolution=node10' has been removed. Please remove it from your configuration.と表示されます。

バンドラー向けのbundler設定とcommonjs併用

Vite、webpack、esbuild、Bunで実行・配布するならbundlerを選びます。5.xではbundlerをmodule: es2015以降のESM形式かpreserveとしか組み合わせられませんでしたが、6.0からmodule: commonjsとの組み合わせが許可されました。moduleを動かさずにmoduleResolutionだけ替えられるので、node10からの差分が最も小さい移行先です。module: commonjs・moduleResolution: bundler・paths相対指定の構成は、6.0.3と7.0.2の両方でエラー0件でした（5.9.3ではTS5095）。

Node.js直接実行向けのnodenext設定

tscの出力をそのままnodeで動かすサーバーやCLIはnodenextにします。moduleもnodenextに揃える必要があり、module: commonjsのままmoduleResolutionだけnode16にするとTS5110になります。nodenextではpackage.jsonの"type"でファイルごとにESMかCommonJSかが決まり、ESM側の相対importには.js拡張子が要ります。修正箇所はimport文全体に及びますが、bundlerはNode.jsのESMで実行できない拡張子なしimportを見逃すため、エラーを消す目的だけで選ばないでください。ESMとCommonJSの違いはESMとCommonJSの違いの解説記事にあります。

NestJS・Docusaurus・tsupが持ち込むbaseUrlの消し方

自分でbaseUrlを書いた覚えがなくても、生成テンプレートやプリセット、ビルドツールが入れていることがあります。エラーにtsconfig.json(6,5)のような行番号が付かずerror TS5101だけが出る場合は、extendsした設定、ビルドツールが渡す設定、tsc --baseUrlのようなコマンドライン引数など、自分の設定ファイルの外から入っています。

NestJS 11で生成したプロジェクトの"baseUrl": "./"

@nestjs/schematics 11.1.0（2026年4月16日公開）のアプリケーション用tsconfig.jsonテンプレートには"baseUrl": "./"が入っており、Nest CLI 11で作ったプロジェクトは6.0でTS5101を出します。12系（12.0.10）のテンプレートからはこの行が消えています。

注意点は、baseUrlがある間にエディタの自動importなどでimport { add } from "src/lib/util"のようなsrc/始まりのパスが書かれているプロジェクトです。baseUrlの行だけ消すとTS2307: Cannot find module 'src/lib/util'になりました。"paths": { "*": ["./*"] }を足すと、tscはエラー0件になり、Nest CLI 12.0.10のnest buildは出力をrequire("./lib/util.js")へ書き換えて、そのまま実行できました。7.0.2のTS5102の文面が提案するUse '"paths": {"*": ["./*"]}' instead.も同じ内容です。時間が取れるときにsrc/始まりのimportを相対パスへ置換し、"*"を外します。

extendsしたDocusaurusプリセットと"baseUrl": null

Docusaurusの@docusaurus/tsconfigは、2026年10月時点のlatest（3.10.2）でも"baseUrl": "."を含んでいます。これをextendsしたサイトでtscを走らせると、行番号なしのTS5101が出ます。Docusaurus側の修正（PR #11915）はv4向けの変更です。サイト構築の全体はDocusaurusの構築手順の記事で扱っています。

待たずに消すには、自分のtsconfigでbaseUrlをnullにして継承を打ち消し、pathsを自分の場所基準で書き直します。

{
  "extends": "@docusaurus/tsconfig",
  "compilerOptions": {
    "baseUrl": null,
    "paths": { "@site/*": ["./*"] }
  }
}

プリセットと同じ内容の設定をextendsして試すと、"baseUrl": nullの有無で6.0.3の結果が変わりました（無しでTS5101、有りでエラー0件）。7.0.2でもエラー0件です。pathsを書き直すのは、継承元のpathsが継承元のディレクトリを基準に解決されるためです。7.0.2のTS5102が提案する"*"マッピングも継承元の場所を指すので、そのまま貼ると意図しない場所を探索します。

tsup 9.0.0で直ったdts生成のbaseUrlとTypeScript 7での使い方

tsup 8.5.1は、dts: trueの型定義生成でbaseUrl: compilerOptions.baseUrl || '.'を内部で渡していました。自分のtsconfigからbaseUrlを消しても、6.0.3では「DTS Build error」とTS5101で失敗します（issue #1388）。2026年10月14日公開のtsup 9.0.0で「Remove baseUrl in tsconfig」（#1390）として修正され、同じプロジェクトが6.0.3でDTS Build successになりました。9.0.0はNode.js 22.18未満のサポートを外しているので、CIのNode.jsの版も確かめます。

TypeScript 7.0.2と組み合わせると、9.0.0でも型定義生成は失敗しました。typescriptを7.0.2にしただけでは「rollup-plugin-dts requires the TypeScript compiler API」で止まり、@typescript/typescript6を追加してもparseJsonConfigFileContent is not a functionで止まります。tsup本体がtypescriptパッケージを直接読むためです。前章のnpmエイリアス構成（typescriptを@typescript/typescript6に向ける）にすると、型定義も生成できました。

非推奨以外で6.0から出るエラーと既定値の変更

6.0は既定値も変えています。strictがtrue、moduleがesnext、targetがes2025相当、noUncheckedSideEffectImportsがtrue、libReplacementがfalse、typesが[]、rootDirがtsconfig.jsonのあるディレクトリです。このうちエラーの原因を読み取りにくいものを3つ挙げます。libReplacementは標準ライブラリの型を別パッケージで差し替える機能で、差し替えていなければ影響はありません。

noUncheckedSideEffectImportsで出るCSS importのTS2882

import "./styles.css"のような副作用だけのimportも、6.0からは解決できないとエラーになります。6.0.3ではTS2882: Cannot find module or type declarations for side-effect import of './styles.css'でした。declare module "*.css";を書いた.d.tsをinclude範囲に置くとCSS側は消え、存在しないパッケージ名の打ち間違いは引き続き検出されます。一律に"noUncheckedSideEffectImports": falseで戻すと、この打ち間違いの検出も失います。

types既定値[]で出るTS2591（processやdescribeが見つからない）

typesの既定が「node_modules/@types を全部読む」から[]に変わりました。@types/nodeを入れてあってもprocessがTS2591: Cannot find name 'process'になります。"types": ["node"]のように必要な型だけ列挙すると解消し、Jestなら"jest"を足します。["*"]で5.9の挙動に戻せますが、公式は明示の列挙を推奨しています。

rootDir既定値の変更で出るTS5011と出力先のずれ

rootDirを書かずにsrc配下だけをビルドしていたプロジェクトは、outDirを使うとTS5011: The common source directory of 'tsconfig.json' is './src'. The 'rootDir' setting must be explicitly setが出ます。放置すると出力がdist/index.jsではなくdist/src/index.jsになるため、"rootDir": "./src"を明示します。設定エラーが出ている間はソースの型エラーが表示されないので、TS5011を直したあとにTS2882やTS2591がまとめて出ることがあります。

よくある質問

baseUrlはTypeScript 6.0で使えなくなりますか？

6.0では使えます。ただしTS5101がerrorとして出て終了コードが非ゼロになるため、CIの型チェックは失敗します。"ignoreDeprecations": "6.0"を付ければ6.0.3ではエラーが消え、探索ルートとしての働きも残ります。使えなくなるのは7.0で、TS5102: Option 'baseUrl' has been removedになり抑止の手段もありません。

"ignoreDeprecations": "6.0"はTypeScript 7.0でも効きますか？

効きません。7.0.2と7.1.0-betaで"6.0"を指定したままビルドすると、baseUrlはTS5102、moduleResolution: nodeはTS5108で止まります。7.0系は"7.0"という値も受け付けますが、削除済みオプションのエラーは消えません。7.0へ上げる前に、該当オプション自体をtsconfigから消す必要があります。

TS5101とTS5107の違いは何ですか？

TS5101はbaseUrlやoutFileのようにオプションそのものが非推奨、TS5107はmoduleResolution=node10やtarget=ES5のように特定の値が非推奨という区別です。7.0では原則としてそれぞれTS5102とTS5108（削除済み）に対応しますが、module: noneはTS6046になります。どちらも該当行を消すか値を替えれば解消します。

Option 'moduleResolution=node10' has been removedと出たらどう直しますか？

TypeScript 7.0でnode10が削除されたというエラーです。Vite・webpack・esbuild・Bunで動かすなら"moduleResolution": "bundler"へ替えます。moduleがcommonjsのままでも組み合わせられます。tscの出力をNode.jsで直接動かすならmoduleとmoduleResolutionを両方nodenextにします。

noUncheckedSideEffectImportsとは何ですか？

import "./polyfill"やimport "./styles.css"のように値を受け取らないimportについても、解決先の存在を検査するオプションです。6.0から既定でtrueになり、CSSなど型宣言の無いファイルでTS2882が出ます。declare module "*.css";を置くとCSS importのエラーを抑止できます。ただし、存在しないCSSファイル名も許容されるため、CSSパスの打ち間違いは検出できません。

関連記事

• TypeScript 6.0とは｜5から6への移行手順とts5to6・7.0との違い【6.0.3対応】
• TypeScript 7とは？Go製ネイティブコンパイラtsgoで最大10倍高速化｜RC公開と移行の要点【2026年最新】
• ESMとCommonJSの違い｜require(esm)で変わった相互運用と移行手順【Node.js 26実測】
• Vite + Reactの環境構築手順｜Viteとは・Vite 8.3の変更点とTypeScript 7対応
• Docusaurusとは：ドキュメントサイトの構築手順とバージョン管理・多言語・検索の設定【3.10対応】