@ts-ignoreを理解する:使用すべきタイミング

TypeScriptの型システムは、本番環境に到達する前にエラーを検出しますが、時にはコンパイラに見逃してもらう必要がある場合があります。そこで登場するのが**@ts-ignore**です。これは、次の行のコードに対してコンパイラエラーを抑制するTypeScriptディレクティブです。特定の状況では救世主となり得ますが、無造作に使用すると、TypeScriptが提供する型安全性そのものを損なうことになります。

この記事では、@ts-ignoreが何をするのか、より安全な@ts-expect-error代替手段とどう異なるのか、そしてコードベースでこれらのTypeScriptディレクティブを使用すべきタイミング(もしあれば)について説明します。

TypeScriptにおける@ts-ignoreの機能

@ts-ignoreディレクティブは、TypeScriptコンパイラに次の行の型チェックをスキップするよう指示するコメントです:

// @ts-ignore
const result: number = "this is actually a string"

このディレクティブがなければ、number型として定義された変数に文字列を代入しているため、TypeScriptはコンパイラエラーを発生させます。@ts-ignoreを使用すると、エラーは永続的かつ静かに消えます。

この動作が@ts-ignoreを特に危険なものにしています。一度追加されると、根本的な問題が修正されてもフィードバックを提供しません。ディレクティブはコード内に残り、将来の変更から生じる新しいTypeScriptコンパイラエラーを隠す可能性があります。

@ts-ignore vs @ts-expect-error: 重要な違い

TypeScript 3.9では**@ts-expect-error**が導入されました。これは@ts-ignoreのより安全な代替手段です。主な違いは何でしょうか?@ts-expect-errorは、次の行にエラーが存在しない場合、ビルドを失敗させます:

// @ts-ignoreの使用(リスクあり)
// @ts-ignore
const value: string = getUserName() // getUserName()修正後も静かなまま

// @ts-expect-errorの使用(より安全)
// @ts-expect-error
const value: string = getUserName() // 修正時に「未使用の'@ts-expect-error'ディレクティブ」をスロー

この自己文書化動作により、@ts-expect-errorはTypeScriptのベストプラクティスにおいて優れています。根本的な問題が解決されたら、ディレクティブを削除することを強制し、コードベース全体で型安全性を維持します。

@ts-ignoreが許容される場合

リスクはありますが、@ts-ignoreが正当な目的を果たす稀なシナリオがあります:

レガシーコードの取り扱い

JavaScriptからTypeScriptへ移行する際、正しく型付けするのが難しい複雑なレガシーパターンに遭遇する可能性があります:

// @ts-ignore - レガシー検証ロジック、Q2にリファクタリング予定
return legacyValidator.validateWithCustomRules(data, rules)

型定義のないサードパーティライブラリ

一部のnpmパッケージにはTypeScript定義がなく、包括的な型を作成することが常に実現可能とは限りません:

// @ts-ignore - ancient-library@1.0.0には@typesパッケージが利用できません
import { processData } from 'ancient-library'

一時的な移行修正

大規模なリファクタリング中、型の更新を完了する前に動作するコードを出荷する必要がある場合があります:

// @ts-ignore - 一時的:User型移行完了後に削除(JIRA-1234)
const user = getOldUserFormat()

@ts-ignoreの過度な使用による隠れたコスト

コードベース内のすべての@ts-ignoreは技術的負債です。以下のリスクがあります:

// ❌ 悪い例:実際のバグを隠す
// @ts-ignore
const total = calculatePrice(items, "invalid-discount-type")

// ✅ より良い例:実際の問題を修正する
const total = calculatePrice(items, DiscountType.PERCENTAGE)

TypeScriptコンパイラエラーを抑制することは以下を意味します:

• TypeScriptが検出できたはずのランタイムバグ
• 型が信頼できなくなることによる困難なリファクタリング
• IDEの自動補完とIntelliSenseサポートの低下
• 型を信頼できないチームメンバーの混乱

ESLintによるより良いプラクティスの強制

TypeScript ESLintプラグインは、ディレクティブの使用を管理するルールを提供します:

{
  "rules": {
    "@typescript-eslint/prefer-ts-expect-error": "error",
    "@typescript-eslint/ban-ts-comment": [
      "error",
      {
        "ts-ignore": "allow-with-description",
        "minimumDescriptionLength": 10
      }
    ]
  }
}

この設定は説明コメントを必須とし、@ts-ignoreよりも@ts-expect-errorを推奨することで、TypeScriptディレクティブをより意図的で追跡可能なものにします。

最初に検討すべきより良い代替手段

@ts-ignoreに手を伸ばす前に、これらのアプローチを試してください:

// オプション1:型アサーション(TypeScriptよりも多くを知っている場合)
const element = document.getElementById('my-id') as HTMLInputElement

// オプション2:型ガード
if (typeof value === 'string') {
  // TypeScriptはvalueが文字列であることを認識します
  console.log(value.toUpperCase())
}

// オプション3:適切な型定義
declare module 'untyped-library' {
  export function someFunction(input: string): number
}

まとめ

@ts-ignoreディレクティブはTypeScriptの非常口です—他に選択肢がない場合にのみ使用してください。ほとんどすべてのケースで、@ts-expect-errorはコードベースにおける説明責任を維持する、より安全な代替手段を提供します。さらに良いのは、適切な型付け、型アサーション、または型ガードに時間を投資して、TypeScriptを価値あるものにする型安全性を保持することです。

覚えておいてください:抑制されたすべてのエラーは、発生を待っている潜在的なバグです。TypeScriptコンパイラエラーを可視化し、型を正直に保ち、@ts-ignoreの使用を可能な限りゼロに保ちましょう。

よくある質問

Complete picture for complete understanding

Capture every clue your frontend is leaving so you can instantly get to the root cause of any issue with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data.

Check our GitHub repo and join the thousands of developers in our community.