TypeScript foi adotado por um motivo direto: capturar erros em tempo de compilação que custariam incidentes em produção. Usar TypeScript sem o modo estrito ativo é manter a sintaxe sem o benefício real. É como usar cinto de segurança sem clicar o encaixe. Strict mode não é configuração avançada — é o mínimo para que TypeScript faça o trabalho para o qual foi criado.

Direto ao ponto:

• TypeScript strict mode elimina categorias inteiras de bugs que any e tipos opcionais mal usados introduzem

• O custo de ativar strict mode em projeto existente é alto; o custo de não ter são bugs de produção indefinidamente

• Code review com TypeScript strict passa falhas que review manual nunca captura

O Que o Strict Mode Realmente Ativa

O strict: true no tsconfig.json não é uma única configuração — é um conjunto de verificações que individualmente parecem menores mas que juntas eliminam classes inteiras de erro:

noImplicitAny força cada valor a ter um tipo explícito. Sem isso, o TypeScript silenciosamente trata valores sem tipo anotado como any — que é essencialmente desligar a verificação de tipos para aquela variável. Em projetos com IA gerando código, como no Vibe Coding, essa verificação é especialmente importante porque a IA pode omitir tipos em alguns contextos.

strictNullChecks é onde a maioria dos bugs de runtime TypeScript se esconde. Sem essa configuração, null e undefined podem ser atribuídos a qualquer tipo sem aviso. Com ela, você é forçado a tratar explicitamente esses casos — o que elimina o TypeError clássico que aparece em produção quando um valor que “nunca deveria ser null” é null.

strictFunctionTypes garante que assinaturas de função são verificadas de forma covariante e contravariante corretamente. É técnico, mas o impacto prático é evitar que callbacks com tipos incompatíveis passem silenciosamente pela verificação.

Por Que Projetos com Vibe Coding Precisam de Strict Obrigatório

Quando você usa Claude Code ou Gemini CLI para gerar código TypeScript, a IA produz código correto segundo o que foi especificado. Mas “correto segundo a especificação” não é a mesma coisa que “tipado adequadamente para produção”.

Agentes de IA tendem a usar any em situações ambíguas, omitir verificações de null em valores que tecnicamente podem ser undefined e usar as para type casting onde a solução correta seria um type guard. Com strict mode ativo e ESLint configurado, esses padrões são capturados antes do commit — não descobertos por um usuário em produção.

O guardrail “TypeScript strict mode é obrigatório” deve fazer parte de qualquer projeto profissional. Não como recomendação — como regra que bloqueia merge se violada.

O Custo de Ativar Strict Mode em Projetos Legados

A razão pela qual muitos projetos nunca ativam strict mode é o custo de migração. Em uma codebase grande que foi desenvolvida sem strict, ativar de uma vez resulta em centenas ou milhares de erros de compilação. É assustador.

A estratégia pragmática é migração incremental:

Ativar as verificações individualmente, começando pelas que capturam mais bugs com menor custo de correção. Criar um segundo tsconfig.strict.json para arquivos novos.

Migrar módulos um por um, priorizando os de maior criticidade de negócio.

A mensagem real aqui é mais simples: projetos novos começam com strict ativo desde o dia um. O custo de migração retroativa é o argumento mais forte para não adiar essa decisão.

TypeScript Como Documentação Viva

Um benefício que vai além da segurança de tipos: TypeScript strict mode força tipos explícitos em interfaces de módulo, retornos de função e parâmetros de callback. Essa explicitidade documenta a intenção do código de uma forma que comentários nunca conseguem.

Quando você lê uma função que recebe user: User e retorna Promise<Order>, você entende o contrato dessa função sem precisar ler a implementação. Quando a mesma função recebe user: any e retorna Promise<any>, você não sabe nada sobre o contrato sem mergulhar no código.

Para projetos com múltiplos devs — ou com IA gerando código ao lado de código humano — essa documentação implícita é um ativo de manutenibilidade que se acumula ao longo do projeto.

TypeScript e o Ecossistema Full-Stack Moderno

Em arquiteturas com Next.js no front-end e Laravel no back-end, TypeScript no front-end com strict mode captura incompatibilidades de contrato de API cedo — especialmente quando combinado com ferramentas de geração de tipos a partir de schemas OpenAPI ou Zod.

Essa integração entre tipagem no front-end e validação no back-end cria uma camada de segurança de ponta a ponta que reduz drasticamente o volume de bugs relacionados a formato e tipo de dados — uma das categorias mais comuns de bug em sistemas client-server.

Perguntas Estratégicas

Vale a pena migrar um projeto legado para TypeScript strict?

Sim, se o projeto vai continuar sendo desenvolvido ativamente. O custo de migração é pago em redução de bugs nas semanas seguintes.

A abordagem incremental por módulo torna isso viável mesmo em codebases grandes.

ESLint resolve os mesmos problemas que TypeScript strict mode?

São complementares, não substitutos. TypeScript strict verifica tipos em tempo de compilação; ESLint captura padrões de código problemáticos em tempo de desenvolvimento.

Os dois juntos criam a camada mais eficaz de qualidade automática disponível no ecossistema JavaScript.

Como garantir que a IA gera código TypeScript strict-compliant?

Duas abordagens combinadas: guardrail explícito no contexto do projeto proibindo any e type assertions sem justificativa, e pipeline de CI que falha o build se TypeScript ou ESLint reportar erros. A automação é mais confiável que a instrução verbal.

Qualidade de Produção É um Hábito, Não um Recurso

A Formação IA Makers ensina TypeScript com strict mode como padrão desde o início — porque produtividade de Vibe Coding sem qualidade técnica é velocidade em direção a dívida técnica.

O código que você vai orgulhosamente mostrar para um potencial cliente ou investidor foi escrito com strict mode ativo. O resto é rascunho.