Comprendre @ts-ignore et quand l'utiliser

Le système de types de TypeScript détecte les erreurs avant qu’elles n’atteignent la production, mais parfois vous devez demander au compilateur de fermer les yeux. C’est là qu’intervient @ts-ignore—une directive TypeScript qui supprime les erreurs du compilateur pour la ligne de code suivante. Bien qu’elle puisse sauver la mise dans des situations spécifiques, l’utiliser sans précaution compromet la sécurité des types que TypeScript offre.

Cet article explique ce que fait @ts-ignore, en quoi elle diffère de l’alternative plus sûre @ts-expect-error, et quand (si jamais) vous devriez utiliser ces directives TypeScript dans votre base de code.

Ce que fait @ts-ignore dans TypeScript

La directive @ts-ignore est un commentaire qui indique au compilateur TypeScript de sauter la vérification de type pour la ligne suivante :

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

Sans cette directive, TypeScript générerait une erreur de compilation car vous assignez une chaîne de caractères à une variable typée comme un nombre. Avec @ts-ignore, l’erreur disparaît—de manière permanente et silencieuse.

Ce comportement rend @ts-ignore particulièrement dangereuse. Une fois ajoutée, elle ne fournit aucun retour si le problème sous-jacent est corrigé. La directive reste dans votre code, masquant potentiellement de nouvelles erreurs du compilateur TypeScript qui surviennent suite à des modifications futures.

@ts-ignore vs @ts-expect-error : une différence cruciale

TypeScript 3.9 a introduit @ts-expect-error, une alternative plus sûre à @ts-ignore. La différence clé ? @ts-expect-error fait échouer la compilation si aucune erreur n’existe sur la ligne suivante :

// Using @ts-ignore (risky)
// @ts-ignore
const value: string = getUserName() // Silent even after fixing getUserName()

// Using @ts-expect-error (safer)
// @ts-expect-error
const value: string = getUserName() // Throws "Unused '@ts-expect-error' directive" when fixed

Ce comportement auto-documenté rend @ts-expect-error supérieure pour les bonnes pratiques TypeScript. Elle vous oblige à retirer la directive une fois le problème sous-jacent résolu, maintenant ainsi la sécurité des types dans votre base de code.

Quand @ts-ignore peut être acceptable

Malgré ses risques, il existe de rares scénarios où @ts-ignore sert un objectif légitime :

Travailler avec du code legacy

Lors de la migration de JavaScript vers TypeScript, vous pourriez rencontrer des patterns legacy complexes difficiles à typer correctement :

// @ts-ignore - Legacy validation logic, refactoring planned for Q2
return legacyValidator.validateWithCustomRules(data, rules)

Bibliothèques tierces sans types

Certains packages npm manquent de définitions TypeScript, et créer des types complets n’est pas toujours faisable :

// @ts-ignore - No @types package available for ancient-library@1.0.0
import { processData } from 'ancient-library'

Corrections temporaires de migration

Lors d’un refactoring à grande échelle, vous pourriez avoir besoin de livrer du code fonctionnel avant de finaliser les mises à jour de types :

// @ts-ignore - Temporary: Remove after completing User type migration (JIRA-1234)
const user = getOldUserFormat()

Les coûts cachés de la surutilisation de @ts-ignore

Chaque @ts-ignore dans votre base de code est une dette technique. Voici ce que vous risquez :

// ❌ Bad: Hiding a real bug
// @ts-ignore
const total = calculatePrice(items, "invalid-discount-type")

// ✅ Better: Fix the actual issue
const total = calculatePrice(items, DiscountType.PERCENTAGE)

Supprimer les erreurs du compilateur TypeScript signifie :

• Des bugs à l’exécution que TypeScript aurait détectés
• Un refactoring plus difficile car les types deviennent peu fiables
• Une autocomplétion IDE et un support IntelliSense réduits
• De la confusion pour les membres de l’équipe qui ne peuvent pas faire confiance aux types

Appliquer de meilleures pratiques avec ESLint

Le plugin TypeScript ESLint fournit des règles pour gérer l’utilisation des directives :

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

Cette configuration exige des commentaires explicatifs et encourage @ts-expect-error plutôt que @ts-ignore, rendant les directives TypeScript plus intentionnelles et traçables.

Meilleures alternatives à considérer en premier

Avant d’utiliser @ts-ignore, essayez ces approches :

// Option 1: Type assertions (when you know more than TypeScript)
const element = document.getElementById('my-id') as HTMLInputElement

// Option 2: Type guards
if (typeof value === 'string') {
  // TypeScript now knows value is a string
  console.log(value.toUpperCase())
}

// Option 3: Proper type definitions
declare module 'untyped-library' {
  export function someFunction(input: string): number
}

Conclusion

La directive @ts-ignore est la sortie de secours de TypeScript—utilisez-la uniquement lorsqu’aucune autre option n’existe. Dans presque tous les cas, @ts-expect-error fournit une alternative plus sûre qui maintient la responsabilité dans votre base de code. Mieux encore, investissez du temps dans un typage approprié, des assertions de type, ou des guards de type pour préserver la sécurité des types qui fait la valeur de TypeScript.

Rappelez-vous : chaque erreur supprimée est un bug potentiel qui attend de se produire. Gardez vos erreurs du compilateur TypeScript visibles, vos types honnêtes, et votre utilisation de @ts-ignore au zéro absolu autant que possible.

FAQ

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.