Cómo funciona @ts-ignore para un bloque: 3 formas en TypeScript

Silencio en el editor: ¿por qué necesitamos bloquear TypeScript?

Cualquiera que haya escrito en TypeScript al menos una semana se ha enfrentado a una situación en la que el compilador empieza a «gritar» sobre un código que, al parecer, funciona. Está seguro de que la lógica es correcta, pero tsc o el IDE resaltan en rojo cada segunda línea. Duele especialmente cuando esto ocurre dentro de un solo bloque: un bucle, una condición o una función.

El // @ts-ignore estándar solo funciona para la siguiente línea. ¿Y qué pasa si necesita «callar» al compilador durante 10–15 líneas seguidas? Copiar el mismo comentario antes de cada línea es un camino a ninguna parte. Esto no solo ensucia el código, sino que también lo hace ilegible.

En este artículo, analizaremos tres enfoques reales para aplicar @ts-ignore a un bloque completo en TypeScript. Aprenderá cuándo es apropiado cada uno y cuándo es mejor renunciar por completo a la supresión de errores. ¡Allá vamos!

El problema: @ts-ignore solo funciona para una línea

Comencemos con un ejemplo básico. Imagine que está trabajando con datos dinámicos de una API, donde los tipos pueden cambiar. Tiene un bloque de código que definitivamente se ejecutará, pero TypeScript se queja de cada acceso a una propiedad.

// Ejemplo: análisis de una respuesta de una API no confiable\nconst data: any = { user: { name: 'Alice', age: 30 } };\n\n// @ts-ignore\nconsole.log(data.user.name); // OK, pero solo una línea\n\n// La siguiente línea volverá a causar un error si no se añade // @ts-ignore\n// console.log(data.user.age); // Error: Property 'age' does not exist on type 'object'\n

Escribir // @ts-ignore antes de cada línea es una mala práctica. Aumenta el volumen de código, dificulta la refactorización y oculta errores reales. Pero hay buenas noticias: TypeScript (a partir de la versión 3.9) y la comunidad han ideado varias soluciones elegantes.

Enfoque 1: @ts-nocheck — fuerza bruta para todo un archivo

La forma más simple, pero también la más radical, es añadir // @ts-nocheck al inicio del archivo. Esto desactiva por completo la verificación de tipos para todo el archivo. Pero nosotros necesitamos un bloque, no todo el archivo. Sin embargo, hay un truco: puede extraer el bloque problemático a un archivo separado e importarlo.

Ventajas:

\n
• Resuelve el problema al instante.
\n
• Adecuado para código heredado que planea reescribir más adelante.
\n

Desventajas:

\n
• Desactiva todas las verificaciones de tipos en el archivo. Puede pasar por alto errores reales.
\n
• No es adecuado para proyectos grandes con reglas de linting estrictas.
\n
• Crea «cajas negras» de código.
\n

// bad.ts — archivo con verificación desactivada\n// @ts-nocheck\nexport function processData(data: any) {\n    const result = data.user.name + ' is ' + data.user.age;\n    return result; // No habrá error, incluso si data es null\n}\n

Cuándo usarlo: Solo para scripts temporales o código heredado que está reescribiendo. Nunca lo use en producción sin una marca explícita TODO.

Enfoque 2: ts-expect-error — un análogo inteligente de @ts-ignore

A partir de TypeScript 3.9, apareció la directiva // @ts-expect-error. Funciona casi como @ts-ignore, pero con una diferencia importante: si no hay error, TypeScript emitirá una advertencia. Esto ayuda a no olvidar eliminar el comentario después de corregir el código.

Pero, ¿cómo aplicar esto a un bloque? La respuesta es que no directamente. @ts-expect-error también funciona solo para una línea. Sin embargo, podemos usar un truco con una función invocada inmediatamente (IIFE).

// Bloque que se debe ignorar, envuelto en una IIFE\n(function() {\n    // @ts-expect-error — esperamos un error en la siguiente línea\n    const x: number = 'hello'; // Error: Type 'string' is not assignable to type 'number'\n\n    // @ts-expect-error — otro error esperado\n    con