TypeScript: por que adotá-lo em projetos modernos

O TypeScript é uma linguagem criada pela Microsoft que adiciona tipos ao JavaScript. Na prática, ele avisa sobre certos erros enquanto você escreve o código, antes de qualquer pessoa abrir o site ou rodar o sistema.

Este texto explica o que ele faz, o que as pesquisas medem sobre os benefícios, por que o tema ganhou peso com os assistentes de programação com IA e como adotá-lo em um projeto que já existe. As informações foram conferidas em 8 de outubro de 2026. Versões e números de adoção mudam rápido, por isso indicamos a data de cada dado.

O que é o TypeScript

O manual oficial resume a ideia em uma frase: o TypeScript é o ambiente de execução do JavaScript com um verificador de tipos em tempo de compilação, segundo a página TypeScript for the New Programmer.

Três conceitos ajudam a entender essa frase.

Um tipo é a descrição do que um valor pode ser: um número, um texto, uma lista de usuários, um objeto com campos específicos.

A verificação estática é a detecção de erros sem executar o programa. O verificador lê o código e compara o uso de cada valor com o tipo esperado.

O superconjunto (superset, em inglês) significa que todo código JavaScript válido também é sintaxe válida em TypeScript. O TypeScript só acrescenta regras sobre como os valores podem ser usados.

Há um ponto que costuma surpreender. Segundo o mesmo manual, depois da verificação o compilador apaga os tipos e gera JavaScript comum. Os tipos não existem quando o programa roda e, como princípio, o TypeScript nunca muda o comportamento do código JavaScript.

O que a verificação pega na prática

O exemplo clássico do manual é um erro de digitação em uma propriedade:

const caixa = { width: 10, height: 20 };
const area = caixa.width * caixa.heigth;
// Erro: a propriedade 'heigth' não existe no tipo { width: number; height: number; }

Em JavaScript puro, esse código roda e produz NaN (o valor especial “não é um número”), sem aviso. O defeito só aparece quando alguém percebe o resultado estranho. Com TypeScript, o editor sublinha o erro na hora.

O mesmo vale para outras situações comuns: passar um texto onde se esperava um número, esquecer um campo obrigatório ou tentar usar um valor que pode ser null (vazio). O manual cita até 4 / [], uma divisão de número por lista que o JavaScript aceita e o TypeScript recusa.

Há também ganhos que não aparecem como erro. Com tipos declarados, o editor sabe o que cada função recebe e devolve. Isso melhora o autocompletar, a navegação até a definição e as renomeações em vários arquivos ao mesmo tempo.

O que as pesquisas dizem sobre tipos e bugs

A pergunta “tipos reduzem bugs?” é antiga e tem respostas menos categóricas do que o marketing sugere.

O estudo mais citado sobre JavaScript é To Type or Not to Type, de Zheng Gao, Christian Bird e Earl T. Barr, apresentado no congresso ICSE de 2017. Os autores pegaram bugs reais de projetos públicos no GitHub, voltaram ao código antes da correção, acrescentaram anotações de tipo e testaram se o TypeScript 2.0 ou o Flow (outro verificador, do Facebook) acusariam erro.

O resultado: os dois verificadores detectaram, em média, 15% dos bugs analisados.

O próprio artigo explica por que esse número tende a subestimar o benefício. Só entram bugs que chegaram ao repositório público, ou seja, que já tinham passado por testes e revisão. Os erros pegos durante o desenvolvimento, antes do commit, ficam de fora. Também não entram ganhos como documentação e autocompletar.

Ao mesmo tempo, o estudo não prova que adotar TypeScript reduz 15% dos defeitos de qualquer projeto. Ele mede o que um verificador teria acusado em uma amostra específica, sob a hipótese de que os desenvolvedores anotariam o código de forma completa.

Pesquisas mais amplas pedem cautela adicional. Uma reanálise publicada por Emery Berger e coautores em 2019, On the Impact of Programming Languages on Code Quality, revisitou um estudo famoso que associava linguagens a defeitos no GitHub. A conclusão foi que só quatro linguagens mantinham associação estatisticamente significativa com defeitos, e com efeito “extremamente pequeno”, nas palavras dos autores.

Na leitura da redação, o conjunto das evidências sustenta uma afirmação moderada: tipos estáticos pegam uma fatia real e mensurável de erros, sobretudo os de “encaixe” entre partes do código. Eles não substituem testes, revisão nem boa arquitetura.

Tipos e código gerado por IA

O argumento ganhou força recente com os assistentes de programação. Modelos de linguagem geram código prevendo um pedaço de texto de cada vez, e nada nesse processo garante que o resultado compile. Para entender por que modelos erram com confiança, veja alucinações de IA.

Um artigo de pesquisadores da ETH Zurich e da UC Berkeley, Type-Constrained Code Generation with Language Models (2025), mediu isso em TypeScript. Na avaliação de modelos abertos de 2 a 34 bilhões de parâmetros, em média 94% dos erros de compilação vinham de falhas na verificação de tipos, e só 6% eram erros de sintaxe.

Isso tem uma consequência prática. Em um projeto tipado, boa parte dos erros que o modelo comete vira uma mensagem clara do compilador, que o próprio agente consegue ler e corrigir. A documentação do Claude Code, por exemplo, lista entre as ferramentas do agente a capacidade de ver erros de tipo depois de cada edição, recurso que depende de plugins específicos para cada linguagem. Explicamos esse ciclo em como funciona o Claude Code.

O GitHub usa o mesmo raciocínio para explicar dados de uso. No relatório Octoverse 2025, publicado em 28 de outubro de 2025, a empresa associa o crescimento do TypeScript à preferência por linguagens tipadas que tornam mais confiável o código feito com agentes. É uma interpretação do GitHub, não um resultado experimental.

Quanto o TypeScript é usado

Dois levantamentos datados dão uma ideia da adoção.

Segundo o Octoverse 2025, em agosto de 2025 o TypeScript passou Python e JavaScript e se tornou a linguagem com mais contribuidores mensais no GitHub: 2.636.006, alta de 66,6% em um ano. O próprio relatório avisa que outros índices, com outras metodologias, ainda podem colocar JavaScript ou Python na frente. O texto também observa que os principais frameworks de interface, como Next.js, Astro, SvelteKit e Angular, já criam projetos em TypeScript por padrão.

Na pesquisa de desenvolvedores do Stack Overflow de 2025, 43,6% de todos os participantes disseram ter trabalhado com TypeScript no último ano, ante 66% para JavaScript. Entre profissionais, a parcela sobe para 48,8%. A pesquisa ficou aberta de 29 de maio a 23 de junho de 2025 e teve 49.009 respostas válidas, segundo a metodologia. É uma amostra de quem responde ao Stack Overflow, não um censo.

O ecossistema em 2026: compilador nativo e Node.js

Duas mudanças recentes reduziram o principal atrito do TypeScript, que era a etapa extra de compilação.

A primeira é o compilador nativo. Em março de 2025, Anders Hejlsberg, arquiteto-chefe da linguagem, anunciou a reescrita do compilador em Go, com meta de ser cerca de dez vezes mais rápido. O TypeScript 7.0 saiu em 8 de julho de 2026. Segundo a Microsoft, compilações completas ficam tipicamente de 8 a 12 vezes mais rápidas. A mesma versão passou a ligar o modo strict por padrão.

O anúncio registra limites. A versão 7.0 não traz ainda uma interface de programação (API) para outras ferramentas, prevista para a 7.1. Por isso, ferramentas que embutem o TypeScript, como as de Vue, Svelte, Astro e MDX, continuam dependendo da versão 6.0 para o suporte no editor.

A segunda mudança está no Node.js, o ambiente que roda JavaScript fora do navegador. Segundo a documentação do Node.js, ele executa arquivos .ts diretamente, removendo os tipos, e esse recurso é estável desde as versões 24.12 e 25.2. O detalhe importante: o Node apenas apaga os tipos e não faz nenhuma verificação. A checagem continua sendo trabalho do compilador tsc ou do editor.

Custos e limites

Adotar TypeScript tem custos, e vale conhecê-los antes.

• Curva de aprendizado. O manual é direto: não dá para aprender TypeScript sem aprender JavaScript. Tipos avançados, como genéricos, levam tempo para dominar.
• Configuração. O arquivo tsconfig.json marca a raiz do projeto e define as opções do compilador, conforme a documentação. Opções mal escolhidas geram atrito com bibliotecas e ferramentas.
• Falsa sensação de segurança. Como os tipos somem na execução, dados que chegam de fora (formulário, API, banco de dados) não são verificados automaticamente. O TypeScript confia no que você declarou. Validar essas entradas em tempo de execução continua necessário.
• A válvula any. O tipo any desliga a verificação para um valor. Usado em excesso, ele anula o benefício sem que ninguém perceba.

Em projetos muito pequenos ou descartáveis, o custo pode superar o ganho. Na avaliação da redação, o benefício cresce com o tamanho do código, o número de pessoas (ou agentes) mexendo nele e o tempo de vida do projeto.

Como adotar sem parar o projeto

A documentação oficial descreve um caminho gradual. Você não precisa converter tudo de uma vez.

1. Verifique arquivos JavaScript primeiro. Segundo a página JS Projects Utilizing TypeScript, basta incluir o comentário // @ts-check na primeira linha de um arquivo .js. Tipos podem ser descritos em comentários no formato JSDoc, um padrão de documentação dentro do código.
2. Deixe os dois convivendo. O guia Migrating from JavaScript recomenda a opção allowJs, que faz o compilador aceitar arquivos .js e .ts no mesmo projeto.
3. Converta um arquivo por vez. O primeiro passo sugerido é renomear um .js para .ts e corrigir o que aparecer.
4. Aperte as regras aos poucos. O guia compara a rigidez do TypeScript a um botão de volume. Primeiro ligue noImplicitAny, que acusa os pontos onde o compilador usaria any sem avisar. Depois, strictNullChecks, que obriga a tratar valores vazios.
5. Chegue ao strict. A opção strict liga de uma vez a família de verificações mais rigorosas. A documentação avisa que versões futuras podem acrescentar checagens a essa família, então uma atualização pode revelar erros novos.

Se o projeto usa agentes de IA, inclua a verificação de tipos (tsc --noEmit, que checa sem gerar arquivos) entre os testes que o agente roda antes de considerar a tarefa pronta e entre as checagens obrigatórias antes de juntar código à versão principal. Descrevemos esse fluxo em Git e GitHub em projetos com IA.

O que levar deste texto

O TypeScript não muda o que o seu programa faz. Ele muda quando você descobre certos erros: no editor, em vez de em produção.

As evidências indicam um ganho real, mas parcial. Algo como 15% dos bugs públicos estudados em 2017 seriam detectáveis por tipos, e em código gerado por modelos de IA a maior parte dos erros de compilação medidos é de tipo. Testes, revisão e validação de dados externos continuam indispensáveis.

Se você vai começar, comece pequeno: // @ts-check em um arquivo, depois allowJs, depois um arquivo .ts, e só então o modo strict. Para ver como isso se encaixa em um MVP feito com agentes, leia como construir um MVP com agentes de IA.