現場で戦うエンジニア諸君、お疲れ様。
「JavaScriptで書いているプロジェクトなのに、なぜか`jsconfig.json`というファイルがある。これって何なの？ TypeScriptの`tsconfig.json`と何が違うの？」
中級者レベルに差し掛かると、一度は抱く疑問だな。結論から言えば、これらは「VS Codeの脳内（言語サービス）」を制御するための設定ファイルだ。ブラウザが直接読むものではない。
今日は、この「設定ファイルの正体」と、実務で明日からドヤ顔で使える設定の勘所を叩き込んでいく。
—
1. そもそも「ブラウザ」はこれらを一切見ていない
まず前提を共有しよう。ブラウザ（ChromeやFirefox）は、`tsconfig.json`や`jsconfig.json`なんて1ミリも知らない。
ブラウザが解釈するのは、あくまで最終的にバンドラ（WebpackやVite）が吐き出したJavaScriptファイルだ。これらの設定ファイルは、主にVS Codeの「インテリセンス（コード補完）」や「型チェック」を司るLanguage Serverに、「このプロジェクトはこういうルールで動いてるよ」と教えるための指示書なんだ。
- tsconfig.json: TypeScriptコンパイラ（`tsc`）の挙動と、VS Code上の型チェックを制御する。
- jsconfig.json: JavaScriptプロジェクトにおいて、TypeScriptコンパイラを使わずにVS Codeの解析機能だけをフル活用するための「型チェックなしのtsconfig」。
つまり、「jsconfig.jsonは、TypeScriptの恩恵を受けたいが、コンパイルのオーバーヘッドを避けたい（あるいはJSのままいきたい）プロジェクトのためのもの」と覚えればいい。
—
2. なぜ「jsconfig.json」を使う必要があるのか？
実務でよくあるのが、「古いJSプロジェクトを少しずつTypeScriptに移行したい」あるいは「JSのままだが、モジュール解決のパスを綺麗に書きたい」というケースだ。
例えば、インポートパスが `../../../components/…` のように汚染されているとき、`jsconfig.json` で `baseUrl` や `paths` を設定すれば、VS Codeはインポート補完を賢くやってくれるようになる。
現場で使える jsconfig.json のサンプル
{
“compilerOptions”: {
“baseUrl”: “src”, // ルートディレクトリを src に設定
“paths”: {
“@/”: [“”] // @/ を src/ 配下としてパス解決させる
},
“target”: “es2020”, // 最近のブラウザ環境に合わせておく
“module”: “esnext”
},
“exclude”: [“node_modules”, “dist”] // 余計な場所は解析対象外にする
}
これを置いておくだけで、VS Codeは `@/components/Button` のようなパスを正しく認識し、定義元へのジャンプも機能するようになる。これこそが、VS CodeをIDEたらしめている正体だ。
—
3. tsconfig.json との「賢い」付き合い方
一方、`tsconfig.json` はより強力だ。`checkJs` プロパティを使うことで、JSファイルに対してTypeScriptの型推論を強制できる。
「いきなり全ファイルを`.ts`にするのはコストが高い」という現場なら、まずは `jsconfig.json` を捨てる。そして、`tsconfig.json` にこう記述するんだ。
実践的：JS混在プロジェクトを徐々に型安全にする設定
{
“compilerOptions”: {
“target”: “esnext”,
“module”: “esnext”,
“strict”: true, // 型チェックを厳格にする
“allowJs”: true, // JSファイルの読み込みを許可
“checkJs”: true, // ここが重要！JSファイルもTypeScriptのルールで検査する
“esModuleInterop”: true,
“skipLibCheck”: true,
“baseUrl”: “./src”
},
“include”: [“src//”]
}
この `checkJs: true` を入れた瞬間、君のJSファイルにTypeScriptの警告（`@ts-check`をファイルの先頭に入れるか、tsconfigで全体適用）が溢れ出すはずだ。「面倒だ」と感じるだろう？ それが成長の痛みだ。
この警告を一つずつ潰していくことこそが、最も効率的なTypeScript移行ロードマップになる。
—
4. 現場のチーフアーキテクトからのアドバイス
最後に、頭の片隅に置いておいてほしいことがある。
1. jsconfig.json は「一時的な処置」と心得よ: JSプロジェクトが少しでも大きくなったら、早急にTypeScriptへ移行すべきだ。JSにおける「型定義の欠如」は、いずれ技術的負債として君たちに牙を剥く。
2. パスエイリアスは設定の要: `paths` を使ったモジュール解決は、開発体験（DX）を劇的に向上させる。ただし、`tsconfig.json` だけで完結させず、ViteやWebpackなどのバンドラ設定側でも同じパス解決ルールを同期させるのを忘れるな。ここがズレると、ビルドエラーという地獄が待っている。
3. VS Codeを信じるな: 最後に頼れるのは `tsc` コマンドだ。VS Code上でエラーが出ていなくても、`tsc –noEmit` を走らせてクリーンな状態を保つ文化をチームに根付かせてくれ。
環境構築は、単なるお作法じゃない。開発中のノイズを減らし、コードの本質に集中するための「防壁」なんだ。
さて、今日はこれくらいにしておこう。まずは自分のプロジェクトの `tsconfig.json` を開いて、`include` や `paths` が正しく設定されているか確認してみろ。意外な発見があるはずだ。
また何か詰まったら聞きに来い。現場からは以上だ。
コメント