Como @ts-ignore funciona para um bloco: 3 maneiras em TypeScript

Silêncio no editor: por que precisamos bloquear o TypeScript?

Todo mundo que escreveu em TypeScript por pelo menos uma semana já enfrentou uma situação em que o compilador começa a "gritar" com um código aparentemente funcional. Você tem certeza de que a lógica está correta, mas o tsc ou a IDE destacam em vermelho cada segunda linha. Dói especialmente quando isso acontece dentro de um único bloco: um loop, uma condição ou uma função.

O padrão // @ts-ignore funciona apenas para a próxima linha. E se você precisar "calar" o compilador por 10 a 15 linhas de uma vez? Copiar o mesmo comentário antes de cada linha é um caminho sem volta. Isso não apenas polui o código, mas também o torna ilegível.

Neste artigo, vamos analisar três abordagens reais de como aplicar @ts-ignore para um bloco inteiro em TypeScript. Você aprenderá quando cada uma é apropriada e quando é melhor abandonar a supressão de erros. Vamos lá!

Problema: @ts-ignore funciona apenas para uma linha

Vamos começar com um exemplo básico. Imagine que você está trabalhando com dados dinâmicos de uma API, onde os tipos podem mudar. Você tem um bloco de código que certamente será executado, mas o TypeScript reclama de cada acesso a propriedade.

// Exemplo: parsing de resposta de uma API não confiável\nconst data: any = { user: { name: 'Alice', age: 30 } };\n\n// @ts-ignore\nconsole.log(data.user.name); // OK, mas apenas uma linha\n\n// A próxima linha causará erro novamente se não adicionar // @ts-ignore\n// console.log(data.user.age); // Error: Property 'age' does not exist on type 'object'\n

Escrever // @ts-ignore antes de cada linha é uma má prática. Isso aumenta o volume de código, dificulta a refatoração e esconde erros reais. Mas também há boas notícias: o TypeScript (a partir da versão 3.9) e a comunidade criaram várias soluções elegantes.

Abordagem 1: @ts-nocheck — força bruta para o arquivo inteiro

A maneira mais simples, mas também a mais radical, é adicionar // @ts-nocheck no início do arquivo. Isso desativa completamente a verificação de tipos para todo o arquivo. Mas precisamos de um bloco, não do arquivo inteiro. No entanto, há um truque: você pode extrair o bloco problemático para um arquivo separado e importá-lo.

Prós:

\n
• Resolve o problema instantaneamente.
\n
• Adequado para código legado que você planeja reescrever depois.
\n

Contras:

\n
• Desativa todas as verificações de tipo no arquivo. Você pode perder bugs reais.
\n
• Não é adequado para projetos grandes com regras de linting rigorosas.
\n
• Cria "caixas-pretas" de código.
\n

// bad.ts — arquivo com verificação desativada\n// @ts-nocheck\nexport function processData(data: any) {\n    const result = data.user.name + ' is ' + data.user.age;\n    return result; // Não haverá erro, mesmo se data for null\n}\n

Quando usar: Apenas para scripts temporários ou código herdado que você está reescrevendo. Nunca use em produção sem uma marcação explícita TODO.

Abordagem 2: ts-expect-error — um análogo inteligente do @ts-ignore

A partir do TypeScript 3.9, surgiu a diretiva // @ts-expect-error. Ela funciona quase como @ts-ignore, mas com uma diferença importante: se não houver erro, o TypeScript emitirá um aviso. Isso ajuda a não esquecer de remover o comentário após corrigir o código.

Mas como aplicar isso a um bloco? A resposta é: diretamente, de jeito nenhum. @ts-expect-error também funciona apenas para uma linha. No entanto, podemos usar um truque com uma função imediatamente invocada (IIFE).

// Bloco a ser ignorado, encapsulado em uma IIFE\n(function() {\n    // @ts-expect-error — esperamos um erro na próxima linha\n    const x: number = 'hello'; // Erro: Type 'string' is not assignable to type 'number'\n\n    // @ts-expect-error — mais um erro esperado\n    con