3 Sistemas de Tipos Que Não São TypeScript

TypeScript é a forma padrão de tipar JavaScript, mas não é a única. Se você já adicionou uma etapa de build a um projeto pequeno apenas para obter algumas anotações de tipo, ou assistiu o tsc percorrer lentamente uma base de código grande, provavelmente já se perguntou se existe uma maneira mais leve de obter segurança de tipos. Existe, e não é apenas uma.

Os três sistemas de tipos não-TypeScript mais relevantes para JavaScript em 2026 são JSDoc com // @ts-check, ReScript e Flow: um oferece verificação de tipos sem etapa de build, outro fornece garantias mais sólidas do que o TypeScript, e o terceiro é um verificador legado que você adotaria apenas para manter código existente. Tudo o que aparece frequentemente em comparações de “alternativas ao TypeScript” (Deno, Dart, Kotlin/JS) é um runtime ou uma linguagem multiplataforma, não um sistema de tipos sobreposto ao JavaScript.

Este é um levantamento comparativo para desenvolvedores que já conhecem TypeScript e querem entender as trocas de forma direta: linguagem versus verificador, etapa de build ou não, solidez em relação ao modelo intencionalmente não-sólido do TypeScript, e a saúde atual de cada ecossistema.

As três alternativas reais ao TypeScript em 2026

Um verdadeiro “sistema de tipos para JavaScript” ou verifica tipos no código-fonte JavaScript (um verificador ou camada de anotações), ou compila uma linguagem tipada para JavaScript. Essa definição inclui JSDoc com @ts-check, ReScript e Flow. Exclui Deno (um runtime que, por acaso, executa TypeScript), e Dart e Kotlin/JS (linguagens separadas que têm JavaScript como um de seus vários backends de saída). Essas ferramentas valem ser conhecidas, mas respondem a uma pergunta diferente.

Para contexto de referência: em meados de 2026, o TypeScript 7.0 é a versão estável atual. Ele foi lançado em 8 de julho de 2026 como uma reescrita nativa do compilador em Go, que a Microsoft relata ser tipicamente de 8x a 12x mais rápido do que o TypeScript 6.0 em builds completos. O TypeScript 6.0 foi o último lançamento construído sobre a base de código JavaScript antiga — uma ponte cujo comportamento de verificação de tipos o 7.0 preserva. Uma lacuna permanece: o 7.0 é lançado sem uma API programática estável, então a verificação de tipos em templates do Vue, Svelte e Angular aguarda o TypeScript 7.1, previsto para outubro de 2026. Tenha isso em mente: isso afeta o que se aplica ao JSDoc, discutido a seguir.

JSDoc + @ts-check: o sistema de tipos do TypeScript sem a etapa de build

O que é: A tipagem baseada em JSDoc permite anotar arquivos .js comuns com comentários estruturados e verificar os tipos usando exatamente o mesmo motor do TypeScript: o serviço de linguagem do TypeScript. Isso é diferente do JSDoc como gerador de documentação; aqui, as anotações conduzem a verificação de tipos. O handbook do TypeScript documenta --checkJs como a flag que reporta erros em arquivos .js, disponível desde o TypeScript 2.3.

Como adotar: Adicione um único comentário ao topo de um arquivo, ou ative duas flags no tsconfig para o projeto inteiro. A documentação JavaScript do VS Code descreve // @ts-check como a forma de experimentar a verificação em alguns arquivos sem habilitá-la em todo o projeto.

// @ts-check

/**
 * @typedef {{ id: number, name: string }} User
 */

/**
 * @param {User} user
 * @returns {string}
 */
function greet(user) {
  return `Hi, ${user.name}`;
}

Para um projeto inteiro, dispense o comentário por arquivo:

{
  "compilerOptions": {
    "allowJs": true,
    "checkJs": true
  }
}

Como os tipos JSDoc são comentários apagáveis, o arquivo é executado como JavaScript padrão em qualquer navegador ou runtime sem etapa de compilação — o que também permite adotá-lo um arquivo por vez. A troca: você herda o modelo do TypeScript exatamente, incluindo sua não-solidez intencional, e a sintaxe de anotação é mais verbosa do que em .ts. Uma observação importante para a era do 7.0: a Microsoft reescreveu a verificação de tipos JavaScript do zero para o TypeScript 7.0 e removeu algumas tags menos utilizadas — o TypeScript 7.0 não reconhece as tags @enum e @constructor.

Quando escolher: Você quer segurança de tipos incremental em uma base de código JavaScript existente, ou uma biblioteca que distribui JS puro, e não quer uma etapa de compilação no caminho.

ReScript: tipos sólidos, nominais e totalmente inferidos

O que é: ReScript é uma linguagem separada que compila para JavaScript — não uma camada de anotações —, com um sistema de tipos herdado do OCaml. O sistema de tipos do TypeScript é intencionalmente não-sólido: ele aceita alguns programas incorretos para manter compatibilidade com a semântica de runtime do JavaScript. Essa é exatamente a lacuna que o ReScript preenche: ele é totalmente inferido e, como o projeto descreve, não tem any, sem tipos mágicos, sem undefined surpresa. Ao contrário da tipagem estrutural do TypeScript, onde qualquer objeto com a forma certa satisfaz um tipo, os records e variants do ReScript são nominais — dois tipos estruturalmente idênticos não são intercambiáveis a menos que declarado explicitamente.

Como adotar: Instale o compilador e configure o rescript.json, o arquivo de build único e obrigatório para um projeto ReScript (era bsconfig.json em versões anteriores ao ReScript 11). O ReScript 12, lançado em 25 de novembro de 2025, remove completamente o suporte ao bsconfig.json e define ES modules como saída padrão.

{
  "name": "my-app",
  "sources": { "dir": "src", "subdirs": true },
  "package-specs": { "module": "esmodule", "in-source": true },
  "suffix": ".res.js"
}

Você pode escolher livremente o sufixo dos arquivos JS gerados; a equipe recomenda .res.js ou .res.mjs, que é o que os templates oficiais do create-rescript-app utilizam. Um módulo mínimo:

let add = (a: int, b: int): int => a + b
let result = add(1, 2)
Console.log(result)

O custo é real: é uma linguagem diferente com sua própria sintaxe, você escreve bindings de interoperabilidade para consumir bibliotecas JavaScript, e o ecossistema é muito menor do que o do TypeScript. Mas o ReScript foi projetado com adoção gradual em mente: se você quiser voltar ao JavaScript puro, basta remover os arquivos-fonte e manter a saída JavaScript limpa.

Quando escolher: Um projeto novo onde você quer as garantias de tipo mais sólidas possíveis e está disposto a se comprometer com uma linguagem, não apenas com anotações.

Flow: ainda existe, em grande parte superado

O que é: Flow é um verificador estático de tipos open-source para JavaScript, criado pelo Facebook/Meta e escrito em OCaml. Assim como o Flow, o ReScript descende do OCaml, mas os dois agora estão em extremos opostos de adoção. Flow é um verificador, não uma linguagem: você anota arquivos .js, marca-os com // @flow, e remove os tipos com Babel no momento do build.

// @flow
function add(a: number, b: number): number {
  return a + b;
}

Realidade de adoção em 2026: O Flow continua em produção dentro da Meta em milhões de arquivos de JavaScript e React, mas seu ecossistema externo se contraiu significativamente: menos definições de bibliotecas, menos tutoriais e ferramental mais escasso do que o TypeScript. A migração de grandes projetos associados à Meta do Flow para o TypeScript tem sido discutida na comunidade, embora nenhuma fonte primária confirme um plano definitivo. Trate comparações antigas do tipo “Flow tem um futuro brilhante” como desatualizadas; o momentum migrou para o TypeScript há anos.

Quando escolher: Realisticamente, apenas quando você está mantendo uma base de código Flow existente. Para qualquer coisa nova, as outras duas opções são apostas mais sólidas.

Veredicto: escolha a ferramenta certa para cada situação

Opte por JSDoc com @ts-check quando quiser tipagem incremental sem nenhuma ferramenta de build e compatibilidade total com JavaScript puro. É a resposta mais subutilizada e mais prática, pois é o próprio verificador do TypeScript apontado para .js. Escolha ReScript quando estiver começando do zero e quiser máxima solidez de tipos, aceitando uma linguagem separada e bindings de interoperabilidade como o preço a pagar. Mantenha o Flow apenas para manter código já escrito nele. Se você quer segurança de tipos sem sair do JavaScript hoje, adicione // @ts-check a um arquivo e observe os erros aparecerem.

Perguntas Frequentes

É possível usar a verificação de tipos JSDoc sem instalar o TypeScript como dependência?

Editores como o VS Code já incluem o serviço de linguagem do TypeScript, então adicionar // @ts-check a um arquivo .js oferece verificação de tipos sem nenhum npm install. Para executar a mesma verificação na linha de comando ou em CI, você instala o pacote typescript e executa tsc com allowJs e checkJs habilitados. Os tipos em si permanecem nos comentários JSDoc, então nada é adicionado ao JavaScript distribuído em nenhum dos casos.

Qual é a diferença entre tipagem estrutural no TypeScript e tipagem nominal no ReScript?

A tipagem estrutural, usada pelo TypeScript, trata qualquer objeto com a forma correta como satisfazendo um tipo — portanto, dois tipos não relacionados com campos idênticos são intercambiáveis. Os records e variants do ReScript são nominais, o que significa que dois tipos estruturalmente idênticos são tratados como distintos a menos que você declare explicitamente uma relação entre eles. A tipagem nominal previne a substituição acidental de tipos com aparência semelhante, o que é parte do motivo pelo qual o sistema do ReScript é sólido onde o do TypeScript é intencionalmente não-sólido.

Por que o Deno não é considerado uma alternativa ao TypeScript nesta comparação?

Deno é um runtime de JavaScript e TypeScript, não um sistema de tipos sobreposto ao JavaScript. Ele executa TypeScript diretamente ao incluir o compilador TypeScript, portanto depende do TypeScript em vez de substituí-lo. Uma alternativa genuína deve ou verificar tipos no código-fonte JavaScript, ou compilar uma linguagem tipada para JavaScript. O mesmo raciocínio exclui Dart e Kotlin/JS, que são linguagens separadas que têm JavaScript como um de seus vários backends de compilação.

Migrar para o TypeScript 7.0 quebra projetos JavaScript com tipagem JSDoc existentes?

Em sua maioria não, mas o TypeScript 7.0 baseado em Go reescreveu a verificação de tipos JavaScript do zero e removeu algumas tags JSDoc menos utilizadas — especificamente @enum e @constructor, que o 7.0 não reconhece mais. Projetos que dependem dessas tags precisam migrá-las para padrões suportados. Tags comuns como @param, @returns, @typedef e @template continuam funcionando, então a maioria das bases de código com tipagem JSDoc migra sem alterações. O TypeScript 7.0 é a versão estável desde julho de 2026, então execute seu projeto nela para ver exatamente o que muda.