--- title: "tsconfigのbaseUrl非推奨（TS5101）の直し方とignoreDeprecations・TypeScript 7.0の削除エラー" url: "https://www.issoh.co.jp/tech/details/11519/" published: 2026-03-25 updated: 2026-10-24 categories: ["TypeScript"] publisher: "株式会社一創" --- # 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の総まとめ記事](/tech/details/11066/)にまとめています。 ## 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は出力ファイルを書き出すため、ローカルのビルドだけ見ていると通ったように見えることがあります。 | tsconfigの設定 | 6.0.3 | 7.0.2・7.1 Beta | 移行先 | | ------------------------------------- | ------ | -------------- | ---------------------- | | `baseUrl` | TS5101 | TS5102 | `paths`を相対指定 | | `moduleResolution: node` | TS5107 | TS5108 | `bundler` / `nodenext` | | `moduleResolution: classic` | TS5107 | TS5108 | `bundler` / `nodenext` | | `target: es5` | TS5107 | TS5108 | `es2015`以上＋外部トランスパイラ | | `downlevelIteration` | TS5101 | TS5102 | 削除 | | `module: amd / umd / system` | TS5107 | TS5108 | バンドラーへ移行 | | `module: none` | TS5107 | TS6046 | バンドラーへ移行 | | `outFile` | TS5101 | TS5102 | バンドラーで結合 | | `esModuleInterop: false` | TS5107 | TS5108 | 削除（常にtrue扱い） | | `allowSyntheticDefaultImports: false` | TS5107 | TS5108 | 削除 | | `alwaysStrict: false` | TS5107 | TS5108 | 削除 | TS5101はオプションそのものの非推奨、TS5107は「オプション＝特定の値」の非推奨です。直し方は同じで、該当行を消すか値を変えます。7.0.2と7.1.0-betaの`baseUrl`と`moduleResolution: node`の番号・文面は同じでした（[7.1 Betaのリリース](https://github.com/microsoft/TypeScript/releases/tag/v7.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の公式リリースノート](https://devblogs.microsoft.com/typescript/announcing-typescript-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](https://github.com/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版で試した結果です。 | 指定した値 | 5.9.3 | 6.0.3 | 7.0.2 | 7.1.0-beta | | ----------------- | ------ | ------ | ------ | ---------- | | `"6.0"` | TS5103 | 受け付ける | 受け付ける | 受け付ける | | `"7.0"` | TS5103 | TS5103 | 受け付ける | 受け付ける | | `baseUrl`と`"6.0"` | TS5103 | 0件 | TS5102 | TS5102 | 7.0.2と7.1 Betaは`"6.0"`も`"7.0"`も値としては受け付けますが、削除済みオプションのエラーは消しません。[7.0の公式発表](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/)も、6.0で非推奨にしたフラグは7.0でハードエラーにすると明記しています。`module`キーワードの名前空間（TS1540）は6.0でも抑止できません。 `ignoreDeprecations`は、6.0に上げた日にCIを通すための一時的な措置です。入れるなら外す期限を課題管理に残しておかないと、7.0へ上げる日にまとめて噴き出します。7.0の全体像や移行の段取りは[TypeScript 7の解説記事](/tech/details/10175/)で扱っています。 ### 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](/tech/details/3351/)を同梱していません。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への移行を段階的に進める場合は、[システムマイグレーション・リプレイス](/service/system/migration/)として計画から引き受けています。 ## 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](https://github.com/jonaskello/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）。 | ツール | 版 | 結果 | 必要な設定 | | -------------- | ---------------- | ------ | ----------------------------- | | tsx | 4.23.15 | 実行できた | なし | | Vite | 8.3.5 | ビルドできた | `resolve.tsconfigPaths: true` | | Jest＋ts-jest | 30.5.2 ＋ 29.4.15 | PASS | `moduleNameMapper` | | tsconfig-paths | 4.2.0 | 失敗 | 実行時用の設定を分ける | Jestはtsconfigの`paths`を読まないので、`moduleNameMapper`が無いと`Cannot find module '@/lib/util'`で失敗します。[ts-jestのpathsToModuleNameMapper](https://kulshekhar.github.io/ts-jest/docs/getting-started/paths-mapping)に`prefix: "/"`を渡すと、`./src/*`の`./`は落とされて`{"^@/(.*)$": "/src/$1"}`が生成され、テストは通りました。Viteは[resolve.tsconfigPaths](https://vite.dev/config/shared-options#resolve-tsconfigpaths)を`true`にした状態で確認しています。Vite 8の設定全体は[Vite + Reactの環境構築記事](/tech/details/3587/)を参照してください。 ## 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の違いの解説記事](/tech/details/12462/)にあります。 ## 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テンプレート](https://github.com/nestjs/schematics/blob/11.1.0/src/lib/application/files/ts/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": "."を含んでいます](https://github.com/facebook/docusaurus/blob/v3.10.2/packages/docusaurus-tsconfig/tsconfig.json)。これをextendsしたサイトで`tsc`を走らせると、行番号なしのTS5101が出ます。Docusaurus側の修正（PR #11915）はv4向けの変更です。サイト構築の全体は[Docusaurusの構築手順の記事](/tech/details/18707/)で扱っています。 待たずに消すには、自分の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](https://github.com/egoist/tsup/releases/tag/v9.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対応】](/tech/details/11066/) - [TypeScript 7とは？Go製ネイティブコンパイラtsgoで最大10倍高速化｜RC公開と移行の要点【2026年最新】](/tech/details/10175/) - [ESMとCommonJSの違い｜require(esm)で変わった相互運用と移行手順【Node.js 26実測】](/tech/details/12462/) - [Vite + Reactの環境構築手順｜Viteとは・Vite 8.3の変更点とTypeScript 7対応](/tech/details/3587/) - [Docusaurusとは：ドキュメントサイトの構築手順とバージョン管理・多言語・検索の設定【3.10対応】](/tech/details/18707/) --- 出典: [tsconfigのbaseUrl非推奨（TS5101）の直し方とignoreDeprecations・TypeScript 7.0の削除エラー]()（株式会社一創）