Entendiendo @ts-ignore y Cuándo Deberías Usarlo

El sistema de tipos de TypeScript detecta errores antes de que lleguen a producción, pero a veces necesitas decirle al compilador que mire hacia otro lado. Ahí es donde entra @ts-ignore—una directiva de TypeScript que suprime los errores del compilador para la siguiente línea de código. Si bien puede ser un salvavidas en situaciones específicas, usarlo descuidadamente socava la misma seguridad de tipos que TypeScript proporciona.

Este artículo explica qué hace @ts-ignore, en qué se diferencia de la alternativa más segura @ts-expect-error, y cuándo (si acaso) deberías recurrir a estas directivas de TypeScript en tu código base.

Qué Hace @ts-ignore en TypeScript

La directiva @ts-ignore es un comentario que le dice al compilador de TypeScript que omita la verificación de tipos para la siguiente línea:

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

Sin la directiva, TypeScript lanzaría un error de compilación porque estás asignando una cadena a una variable tipada como número. Con @ts-ignore, el error desaparece—permanente y silenciosamente.

Este comportamiento hace que @ts-ignore sea particularmente peligroso. Una vez agregado, no proporciona retroalimentación si el problema subyacente se corrige. La directiva permanece en tu código, potencialmente ocultando nuevos errores del compilador de TypeScript que surgen de cambios futuros.

@ts-ignore vs @ts-expect-error: Una Diferencia Crítica

TypeScript 3.9 introdujo @ts-expect-error, una alternativa más segura a @ts-ignore. ¿La diferencia clave? @ts-expect-error falla la compilación si no existe ningún error en la siguiente línea:

// Usando @ts-ignore (riesgoso)
// @ts-ignore
const value: string = getUserName() // Silencioso incluso después de corregir getUserName()

// Usando @ts-expect-error (más seguro)
// @ts-expect-error
const value: string = getUserName() // Lanza "Unused '@ts-expect-error' directive" cuando se corrige

Este comportamiento auto-documentado hace que @ts-expect-error sea superior para las mejores prácticas de TypeScript. Te obliga a eliminar la directiva una vez que se resuelve el problema subyacente, manteniendo la seguridad de tipos en toda tu código base.

Cuándo @ts-ignore Podría Ser Aceptable

A pesar de sus riesgos, hay escenarios raros donde @ts-ignore sirve un propósito legítimo:

Trabajando con Código Heredado

Al migrar JavaScript a TypeScript, podrías encontrar patrones heredados complejos que son difíciles de tipar correctamente:

// @ts-ignore - Lógica de validación heredada, refactorización planificada para Q2
return legacyValidator.validateWithCustomRules(data, rules)

Bibliotecas de Terceros Sin Tipos

Algunos paquetes npm carecen de definiciones de TypeScript, y crear tipos completos no siempre es factible:

// @ts-ignore - No hay paquete @types disponible para ancient-library@1.0.0
import { processData } from 'ancient-library'

Correcciones Temporales de Migración

Durante refactorizaciones a gran escala, podrías necesitar enviar código funcional antes de completar las actualizaciones de tipos:

// @ts-ignore - Temporal: Eliminar después de completar la migración del tipo User (JIRA-1234)
const user = getOldUserFormat()

Los Costos Ocultos de Usar en Exceso @ts-ignore

Cada @ts-ignore en tu código base es deuda técnica. Esto es lo que arriesgas:

// ❌ Malo: Ocultando un error real
// @ts-ignore
const total = calculatePrice(items, "invalid-discount-type")

// ✅ Mejor: Corregir el problema real
const total = calculatePrice(items, DiscountType.PERCENTAGE)

Suprimir errores del compilador de TypeScript significa:

• Errores en tiempo de ejecución que TypeScript habría detectado
• Refactorización más difícil ya que los tipos se vuelven poco confiables
• Soporte reducido de autocompletado e IntelliSense del IDE
• Confusión para los miembros del equipo que no pueden confiar en los tipos

Aplicando Mejores Prácticas con ESLint

El plugin TypeScript ESLint proporciona reglas para gestionar el uso de directivas:

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

Esta configuración requiere comentarios explicativos y fomenta @ts-expect-error sobre @ts-ignore, haciendo que las directivas de TypeScript sean más intencionales y rastreables.

Mejores Alternativas a Considerar Primero

Antes de recurrir a @ts-ignore, prueba estos enfoques:

// Opción 1: Aserciones de tipo (cuando sabes más que TypeScript)
const element = document.getElementById('my-id') as HTMLInputElement

// Opción 2: Guardias de tipo
if (typeof value === 'string') {
  // TypeScript ahora sabe que value es una cadena
  console.log(value.toUpperCase())
}

// Opción 3: Definiciones de tipo apropiadas
declare module 'untyped-library' {
  export function someFunction(input: string): number
}

Conclusión

La directiva @ts-ignore es la salida de emergencia de TypeScript—úsala solo cuando no exista otra opción. En casi todos los casos, @ts-expect-error proporciona una alternativa más segura que mantiene la responsabilidad en tu código base. Mejor aún, invierte tiempo en tipado apropiado, aserciones de tipo o guardias de tipo para preservar la seguridad de tipos que hace valioso a TypeScript.

Recuerda: cada error suprimido es un error potencial esperando a suceder. Mantén los errores del compilador de TypeScript visibles, tus tipos honestos y tu uso de @ts-ignore en cero absoluto siempre que sea posible.

Preguntas Frecuentes

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.