【テクニカル・上級編】 jsconfig.jsonとcheckJsによる型チェックの有効化 – JavaScript実践ガイド

ゆるふわJavaScriptに別れを告げよ：`jsconfig.json` と `checkJs` で実現する、TypeScriptを導入しない型安全の極限

夜な夜なコードレビューをしていると、未だに見かけるんだよね。
「うちはTypeScriptを導入するコスト（ビルドパイプラインの複雑化、チームの学習コスト）を嫌って、プレーンなJavaScriptでSPAを作っています」という現場。

気持ちは分からなくもない。あの `tsconfig.json` の設定地獄や、`.d.ts` ファイルの管理、そして「ちょっと書きたいだけなのにビルドが通らない」というストレスから逃れたい衝動は、プログラマーなら誰しも共感するはずだ。

だが、ちょっと待ってほしい。
「TypeScriptの静的解析メリットだけを、ビルドの苦痛なしに丸ごといただく」 という選択肢があることを忘れていないかい？

そう、それが今回スポットを当てる `jsconfig.json` と `checkJs: true` のコンビネーションだ。

VS Codeなどのモダンなエディタが内部で持っているTypeScript言語サービス（TSServer）をフル活用し、プレーンなJavaScriptのまま、型安全の要塞を築き上げる。今回は、このいぶし銀な設定がいかにして大規模フロントエンドのメモリ効率やランタイムエラーの撲滅に寄与するか、そのアーキテクチャの核心を語り尽くそう。

—

なぜ `typeof` や JSDoc だけでは大規模開発に耐えられないのか

JavaScriptの動的な性質は、プロトタイピングのスピードにおいては最強の武器だ。しかし、コードベースが10万行を超えてくると、その柔軟さは「時限爆弾」へと変貌する。

よくあるアンチパターンを見てみよう。非同期APIから取得したユーザーデータのプロパティ名をタイポしたとき、君たちはどうやってそれに気づいている？

// 【地獄の始まり】何の変哲もない非同期データ取得関数
async function fetchUserProfile(userId) {
const response = awaitこう(`https://api.example.com/users/${userId}`);
const user = await response.json();

// うっかり property 名をタイポしているが、JavaScriptのエンジンは優しすぎるので文句を言わない
return {
fullName: user.ful_name, // 正しくは user.full_name
isActive: user.status === ‘active’
};
}

このエラーが発覚するのは、決まってプロダクション環境、しかもユーザーが特定のボタンを押した瞬間だ。非同期の競合状態（レースコンディション）や、レンダリング負荷の最適化の最中に、こういうundefined参照によるバグが混入すると、デバッグのコストは跳ね上がる。

「じゃあ実行時に `typeof` でガードを入れよう」って？
ちょっと待て。すべての関数でランタイムの型チェックを行っていたら、V8エンジンのインラインキャッシュ（Inline Caching）の効きが悪くなり、ガベージコレクション（GC）のプレッシャーが増大する。パフォーマンスの観点からも、型チェックは実行時ではなく、エディタの静的解析（コンパイル前）の段階で完全に終わらせておくべきだ。

そこに光を当てるのが、`jsconfig.json` による静的型強制である。

—

`jsconfig.json` と `checkJs` の魔力：ビルドなしの静的解析

プロジェクトのルートディレクトリに `jsconfig.json` を配置するだけで、VS Codeの振る舞いは劇的に変わる。TypeScriptのコンパイラ（tsc）が裏で動き出し、JavaScriptファイル（`.js` や `.mjs`）をTypeScriptと同等の厳密さで解釈し始めるのだ。

最小限にして最強の `jsconfig.json` の設定を見てほしい。

{
“compilerOptions”: {
“target”: “ESNext”,
“module”: “ESNext”,
“checkJs”: true, // ここが命！JSファイルに対する型チェックを強制する
“noEmit”: true, // JSからJSへの変換やトランスパイルを行わない（ビルド生成物を出力しない）
“strict”: true, // 厳格なnullチェックなど、すべての型安全フラグをONにする
“esModuleInterop”: true, // CommonJSとES Modulesの互換性を担保
“jsx”: “react” // Reactを使っているならJSXのパースも有効に
},
“include”: [“src//”] // 解析対象のスコープ
}

注目すべきは `”noEmit”: true` だ。
これにより、TypeScript特有のビルドステップやバンドラーへの統合を追加する必要が一切なくなる。ブラウザや既存のWebpack/Viteのビルドパイプラインはそのままに、開発者体験（DX）のフェーズだけでTypeScriptの強力な恩恵を丸パクリできるというわけだ。

—

JSDoc との融合：プレーンJSで最高峰の型安全を記述する

`checkJs: true` を有効にすると、エディタはJavaScript内の JSDoc（`/ … /`）をただのコメントではなく「型定義」として解釈し始める。

TypeScriptの構文（`const user: User = …`）はJavaScriptの仕様外なのでそのままでは書けないが、JSDocを使えば、プレーンなJavaScriptの文法を1ミリも汚さずに、完全な型安全を実現できる。

実務で即座に使える、高度なJSDocの活用例を示そう。

// @ts-check
// ↑ ファイルの先頭にこれを書くことで、jsconfig.jsonの設定を明示的にこのファイルに強制できる

@typedef {Object} User
@property {string} id – ユーザーを一意に特定するUUID
@property {string} fullName – ユーザーのフルネーム
@property {‘admin’ | ‘user’ | ‘guest’} role – 権限レベル（リテラル型で制限）

非同期でユーザーデータをキャッシュ付きで取得する関数
メモリリークを防ぐため、 WeakMap を用いたメモ化のアーキテクチャ
@param {string} userId – 取得対象のユーザーID
@returns {Promise} ユーザー情報のプロミス

/
export async function fetchUserWithCache(userId) {
// ここで仮にプロパティのタイポや、不適切な型の代入があると、
// エディタが即座に赤波線（Red Squiggly）で警告を出してくれる。

const response = await fetch(`https://api.example.com/users/${userId}`);

/ @type {User} /
const user = await response.json();

return user;
}

このアプローチの何が素晴らしいって、「JSDocはあくまでコメントであるため、万が一環境が変わってもそのまま通常のJavaScriptとして動作する」という点にある。メタプログラミングや動的なコード生成を行う際も、TypeScriptのパーサーに縛られるストレスがない。

—

高度なアーキテクチャ設計：非同期の競合とメモ化の型安全

フロントエンドのパフォーマンス最適化において、非同期処理の競合（Race Condition）と不要なレンダリングの抑制は永遠の課題だ。ここでも `jsconfig.json` と `checkJs` は強力な盾となる。

例えば、複数の非同期リクエストが走った際に、古いレスポンスが新しいレスポンスを上書きしてしまうバグを防ぐためのヘルパー関数を、完全に型安全なJSで書いてみよう。

// @ts-check

競合状態（Race Condition）を防ぐための非同期ラッパーファクトリー
@template T
@returns {(promise: Promise) => Promise}

/
export function createLatestResolver() {
let latestRequestId = 0;

return async (promise) => {
const currentId = ++latestRequestId;
const result = await promise;

// もしこの非同期処理の途中で新しいリクエストが走っていたら、結果を破棄する
if (currentId !== latestRequestId) {
return null;
}

return result;
};
}

// — 使用例 —
const resolveLatest = createLatestResolver();

async function handleSearchInput(keyword) {
const searchPromise = api.search(keyword);

// 型推論により、result はユーザー定義型または null であることが保証される
const result = await resolveLatest(searchPromise);
if (!result) return; // 古いリクエストの結果ならここで処理をスルー

renderSearchResults(result);
}

JSDocの `@template T` を使うことで、プレーンなJavaScriptでありながら、ジェネリクス（Generics）の恩恵をフルに受けることができる。これにより、複雑な非同期パイプラインであっても、型のほころびをコンパイル前にすべて検知できるのだ。

—

チーフアーキテクトからの提言：なぜ今、この手法を選ぶべきか

世の中のトレンドは「とりあえずTypeScript」かもしれない。しかし、既存の大規模なJavaScriptコードベースを抱えるチームや、ビルドツールチェインの複雑性を極限まで排除したいミニマリストなプロジェクトにおいて、TypeScriptの導入は時としてオーバースペックであり、組織的な負債になる。

`jsconfig.json` と `checkJs: true` の組み合わせは、そのジレンマに対する最もエレガントで実用的な回答だ。

1. ゼロ・ビルドコスト: トランスパイルや型の型定義ファイルの生成（`.d.ts` emit）に悩まされない。
2. 段階的な導入: プロジェクト全体を一気に書き換える必要はなく、ファイルの先頭に `// @ts-check` を1行追加するだけで、ミッションクリティカルなファイルから順次型安全にできる。
3. エディタの全脳化: VS Codeの強力なインテリセンスと静解析が、あなたのタイポや不安全な代入を水際で食い止めてくれる。

道具に振り回されるな。JavaScriptの身軽さを維持したまま、最高峰の堅牢性を手に入れろ。
明日から、いや、今すぐあなたのプロジェクトのルートに `jsconfig.json` を置き、`”checkJs”: true` を叩き込んでみるんだ。エディタの赤波線の向こう側に、新しい世界が広がっているはずだ。