Comment @ts-ignore fonctionne pour un bloc : 3 méthodes en TypeScript

Silence dans l'éditeur : pourquoi bloquer TypeScript ?

Quiconque a écrit en TypeScript ne serait-ce qu'une semaine a déjà rencontré une situation où le compilateur se met à « crier » sur un code pourtant fonctionnel. Vous êtes sûr que la logique est correcte, mais tsc ou l'IDE surligne en rouge une ligne sur deux. C'est particulièrement douloureux lorsque cela se produit à l'intérieur d'un même bloc : une boucle, une condition ou une fonction.

Le // @ts-ignore standard ne fonctionne que pour la ligne suivante. Mais que faire si vous devez « faire taire » le compilateur sur 10 à 15 lignes d'un coup ? Copier le même commentaire devant chaque ligne est une impasse. Non seulement cela encombre le code, mais cela le rend également illisible.

Dans cet article, nous allons analyser trois approches concrètes pour appliquer @ts-ignore à un bloc entier en TypeScript. Vous découvrirez quand chacune est appropriée, et quand il vaut mieux renoncer complètement à la suppression des erreurs. C'est parti !

Le problème : @ts-ignore ne fonctionne que sur une seule ligne

Commençons par un exemple de base. Imaginez que vous travaillez avec des données dynamiques provenant d'une API, où les types peuvent changer. Vous avez un bloc de code qui s'exécutera à coup sûr, mais TypeScript se plaint à chaque accès à une propriété.

// Exemple : analyse d'une réponse d'une API non fiable\nconst data: any = { user: { name: 'Alice', age: 30 } };\n\n// @ts-ignore\nconsole.log(data.user.name); // OK, mais une seule ligne\n\n// La ligne suivante provoquera à nouveau une erreur si // @ts-ignore n'est pas ajouté\n// console.log(data.user.age); // Error: Property 'age' does not exist on type 'object'\n

Écrire // @ts-ignore devant chaque ligne est une mauvaise pratique. Cela augmente le volume de code, complique le refactoring et masque les véritables erreurs. Mais il y a de bonnes nouvelles : TypeScript (à partir de la version 3.9) et la communauté ont imaginé plusieurs solutions élégantes.

Approche 1 : @ts-nocheck — la force brute pour un fichier entier

La méthode la plus simple, mais aussi la plus radicale, consiste à ajouter // @ts-nocheck au début du fichier. Cela désactive complètement la vérification des types pour l'ensemble du fichier. Mais nous avons besoin d'un bloc, pas de tout le fichier. Cependant, il existe une astuce : vous pouvez extraire le bloc problématique dans un fichier séparé et l'importer.

Avantages :

\n
• Résout le problème instantanément.
\n
• Convient au code legacy que vous prévoyez de réécrire plus tard.
\n

Inconvénients :

\n
• Désactive toutes les vérifications de types dans le fichier. Vous pourriez passer à côté de véritables bugs.
\n
• Ne convient pas aux grands projets avec des règles de linting strictes.
\n
• Crée des « boîtes noires » dans le code.
\n

// bad.ts — fichier avec vérification désactivée\n// @ts-nocheck\nexport function processData(data: any) {\n    const result = data.user.name + ' is ' + data.user.age;\n    return result; // Aucune erreur, même si data est null\n}\n

Quand l'utiliser : Uniquement pour des scripts temporaires ou du code hérité que vous êtes en train de réécrire. Ne l'utilisez jamais en production sans une mention explicite TODO.

Approche 2 : ts-expect-error — l'analogue intelligent de @ts-ignore

Depuis TypeScript 3.9, la directive // @ts-expect-error est apparue. Elle fonctionne presque comme @ts-ignore, mais avec une différence importante : si l'erreur est absente, TypeScript émettra un avertissement. Cela aide à ne pas oublier de supprimer le commentaire après avoir corrigé le code.

Mais comment l'appliquer à un bloc ? Réponse : pas directement. @ts-expect-error ne fonctionne également que sur une seule ligne. Cependant, nous pouvons utiliser une astuce avec une fonction immédiatement invoquée (IIFE).

// Bloc à ignorer, enveloppé dans une IIFE\n(function() {\n    // @ts-expect-error — nous attendons une erreur à la ligne suivante\n    const x: number = 'hello'; // Error: Type 'string' is not assignable to type 'number'\n\n    // @ts-expect-error — une autre erreur attendue\n    con