TypeScript strict: vale a pena ativar? Comparativo

Ativar o TypeScript strict não é só uma flag no tsconfig: é uma mudança de contrato entre você e o compilador. O modo normal aceita atalhos que passam batido em revisão. O strict fecha essas brechas, mas cobra o preço em ajustes. A pergunta certa não é qual é melhor em abstrato, e sim qual encaixa no estágio do seu projeto.

O que cada modo realmente verifica

O modo normal do TypeScript faz checagem de tipos básica. Você pode declarar uma variável sem tipo explícito, acessar propriedades de um objeto possivelmente nulo e passar adiante sem que o compilador reclame. Já o strict liga um pacote de flags, sendo as mais conhecidas strictNullChecks e noImplicitAny. Com elas, null e undefined deixam de ser coringas e todo any implícito vira erro.

A diferença prática aparece em runtime. Um user.name.toUpperCase() que compila no modo normal pode estourar em produção se user vier nulo da API. No strict, o compilador obriga você a tratar esse caso antes do deploy.

Segurança de tipos na prática

Em projetos novos, o strict tende a ser a escolha padrão da comunidade TypeScript, como indica a própria documentação oficial da linguagem. O motivo é simples: quanto antes o erro aparece, mais barato corrigir. Um noImplicitAny ativo evita que funções sem tipagem se espalhem pelo código e contaminem módulos inteiros.

O contraexemplo é uma base legada com centenas de arquivos. Ligar o strict de uma vez pode gerar milhares de erros e paralisar o time por semanas. Nesse cenário, o modo normal com ativação gradual por pasta costuma ser mais realista.

Curva de aprendizado e produtividade

Para quem está começando, o strict exige entender melhor tipos utilitários, uniões e narrowing. Isso adiciona algumas horas de estudo, mas reduz o tempo gasto caçando bugs de undefined em produção. Desenvolvedores experientes costumam relatar que o ganho compensa depois do primeiro mês.

No modo normal, a produtividade inicial é maior porque o compilador perdoa mais. O custo vem depois, em debugging e em refatorações arriscadas. Não existe almoço grátis, só a decisão de quando pagar a conta.

Migração e custo de adoção

| Critério | Modo normal | TypeScript strict | |---|---|---| | Erros pegos em compilação | Poucos | Muitos | | Tempo de setup em projeto novo | Baixo | Médio | | Custo em base legada | Baixo | Alto no início | | Segurança em runtime | Menor | Maior | | Refatoração segura | Limitada | Ampla |

A estratégia mais usada em bases grandes é ativar o strict por módulo, começando pelos arquivos novos. O tsconfig permite isso com configurações separadas, e muitos times adotam essa transição ao longo de meses.

Veredito: qual escolher

Para projetos novos, bibliotecas publicadas e times que valorizam refatoração segura, o TypeScript strict é a escolha recomendada. O esforço inicial se paga em menos bugs e em código mais previsível.

Para bases legadas extensas, protótipos rápidos ou equipes em transição de JavaScript, o modo normal ainda tem espaço. O ideal é tratá-lo como ponto de partida, não como destino final, e planejar a adoção gradual do strict.

Perguntas frequentes

O que o TypeScript strict ativa exatamente?

O strict é um atalho que liga várias flags de checagem, incluindo strictNullChecks, noImplicitAny, strictFunctionTypes e strictPropertyInitialization. Cada uma cobre um tipo de erro diferente, e juntas tornam o compilador bem mais rigoroso.

Posso ativar o strict aos poucos?

Sim. O tsconfig permite ativar flags individualmente ou usar configurações por pasta. Times costumam começar por strictNullChecks e noImplicitAny, que resolvem a maior parte dos problemas de runtime.

O strict deixa o código mais lento para escrever?

No começo sim, porque exige tipar melhor e tratar casos nulos. Depois de algumas semanas, a diferença cai e o tempo economizado em debug costuma superar o esforço inicial.

Vale a pena usar strict em projeto pequeno?

Vale. Em projetos pequenos o custo de adoção é baixo e o benefício aparece rápido. Ativar desde o início evita que a dívida técnica se acumule conforme o código cresce.

O que acontece se eu desligar o strict depois?

Você perde as garantias de tipo e volta a aceitar null e any implícitos. Isso pode reabrir bugs já resolvidos, então desligar deve ser decisão consciente e documentada no time.