Resposta rápida: a Microsoft integrou hoje a implementação em Go do TypeScript 7 ao repositório principal microsoft/TypeScript. O PR #63763 entrou na branch main em 20 de agosto de 2026. O merge usou o commit 6d44e05 e concluiu 23 verificações com sucesso.
O TypeScript 7.0 já tinha sido lançado em 8 de julho de 2026. Portanto, o evento de hoje não é uma nova versão. Ele reúne novamente o desenvolvimento do TypeScript em um único repositório, depois do trabalho temporário em microsoft/typescript-go.
A distinção mais importante é simples: programas TypeScript não passaram a compilar para Go. A implementação do compilador tsc e das ferramentas de linguagem usa Go. O TypeScript continua tendo JavaScript como destino para o código dos usuários.
O que o PR #63763 mudou
O PR não fez uma simples cópia da versão atual dos arquivos. A equipe reaplicou todo o histórico do repositório typescript-go dentro de microsoft/TypeScript. O processo preservou histórico Git, blame, autoria e créditos dos commits.
As referências antigas em mensagens de commit também foram ajustadas. Uma referência como microsoft/typescript-go#1234, por exemplo, continua apontando para o item original depois da migração.
O código em Go ficou no diretório tsc do repositório principal. A equipe escolheu esse diretório para evitar conflitos com tags Git que já existiam no projeto. O módulo aninhado ainda não tem versão própria e não exporta uma API pública em Go.
O merge também removeu da branch main a implementação anterior, conhecida pelo codinome Strada. Essa base era escrita em TypeScript e JavaScript. A equipe manteve arquivos selecionados, como licenças, scripts e workflows do GitHub Actions.
Depois do merge principal, commits de ajuste corrigiram imports, nomes de pacotes e a organização de arquivos. O resultado é que o desenvolvimento ativo do TypeScript voltou ao repositório original.
A linha do tempo evita uma confusão importante
Três eventos diferentes formam esta história:
| Evento | Data | O que aconteceu |
|---|---|---|
| Anúncio do port nativo | 2025 | A Microsoft apresentou o plano de portar o compilador e as ferramentas para Go |
| Lançamento do TypeScript 7.0 | 8 de julho de 2026 | A versão nativa em Go ficou disponível pelo pacote oficial typescript |
| Merge do PR #63763 | 20 de agosto de 2026 | O código e o histórico voltaram ao repositório microsoft/TypeScript |
O repositório microsoft/typescript-go serviu como área temporária durante o port. Ele agora está fechado para novo desenvolvimento. O aviso oficial informa que a Microsoft pretende arquivá-lo permanentemente em setembro de 2026.
Assim, a notícia de hoje marca uma mudança de organização e governança. Ela não marca o lançamento inicial do TypeScript 7 nem uma segunda troca de compilador.
Por que a Microsoft escolheu Go
A explicação oficial da equipe começa com uma restrição central: o projeto precisava de um port compatível, não de uma reescrita livre.
O compilador acumulou muitos comportamentos, otimizações e casos especiais. Uma implementação nova, com outra arquitetura, poderia produzir erros diferentes ou alterar detalhes observáveis. A equipe queria manter a semântica e a estrutura próximas da base anterior.
Go se encaixou nesse plano por quatro motivos principais.
1. O código existente já usava funções e estruturas de dados
A base do TypeScript não dependia de uma arquitetura centrada em classes. Ela usava muitas funções e estruturas de dados. Segundo a equipe, o Go idiomático permitiu manter uma forma parecida.
Essa proximidade tornou o port mais direto. Ela também facilitou a comparação entre as duas implementações durante a transição.
2. Compiladores trabalham com árvores e grafos complexos
Um compilador mantém árvores sintáticas, tipos recursivos, referências entre nós e vários grafos internos. O TypeScript também percorre essas estruturas em diferentes direções.
Go permitiu representar esses relacionamentos sem redesenhar todo o compilador. A garbage collection ajudou a manter referências complexas sem exigir gestão manual da memória.
3. Go oferece controle de layout sem gestão manual de memória
A equipe queria controlar o layout dos objetos e as alocações. Esses detalhes afetam cache de CPU, memória total e velocidade do compilador.
Go oferece esse controle e mantém a garbage collection. No caso do TypeScript, muitas estruturas vivem durante toda a execução. Em builds de lote, o processo também termina logo depois da compilação. Esse perfil reduz parte do custo prático do coletor.
4. A implementação nativa usa memória compartilhada e paralelismo
O TypeScript 7 paraleliza etapas como parsing, verificação de tipos e emissão. O novo compilador pode usar vários núcleos com memória compartilhada, sem criar processos isolados para cada tarefa.
Esse modelo conversa diretamente com temas de concorrência em Go e com as primitivas do pacote sync. Porém, o resultado não vem somente da escolha da linguagem. A Microsoft combinou código nativo, paralelismo e novas otimizações.
Os benchmarks oficiais: builds entre 8x e 12x mais rápidos
No anúncio oficial do TypeScript 7.0, a Microsoft informa ganhos típicos de 8x a 12x em builds completos. Estes números vêm dos testes da própria Microsoft, não de um benchmark independente.
| Projeto | TypeScript 6 | TypeScript 7 | Ganho | Memória |
|---|---|---|---|---|
| VS Code | 125,7 s | 10,6 s | 11,9x | -18% |
| Sentry | 139,8 s | 15,7 s | 8,9x | -6% |
| Playwright | 12,8 s | 1,47 s | 8,7x | -11% |
Na lista completa da Microsoft, a redução de memória ficou entre 6% e 26%. Os resultados variam conforme o projeto, a máquina, o número de núcleos e a configuração dos workers.
Os números mostram o efeito do sistema completo. Eles não isolam quanto veio de Go, do código nativo, do novo desenho paralelo ou de outras otimizações. Essa é a forma correta de ler qualquer comparação de performance.
Para equipes Go, a lição continua conhecida: meça a carga real antes de concluir. O guia de pprof em produção mostra como investigar CPU e memória em aplicações próprias.
O que isso significa para desenvolvedores Go
A mudança coloca uma base grande e madura em Go dentro do repositório oficial do TypeScript. Isso dá à comunidade Go um caso público de uso em compiladores e ferramentas de desenvolvimento.
O caso também mostra uma escolha pragmática. A equipe não buscou a linguagem mais rápida em um teste isolado. Ela buscou uma linguagem que preservasse o desenho existente, aceitasse grafos complexos e permitisse usar vários núcleos.
Há outra lição importante: garbage collection e performance não formam uma oposição automática. O perfil de alocação e o tempo de vida dos objetos determinam o custo real. Para essa base, a equipe considerou que a simplicidade da gestão de memória compensava o custo do coletor.
O código agora pode ser estudado no diretório tsc por pessoas interessadas em compiladores escritos em Go. Porém, o módulo ainda não é uma biblioteca pública. Não importe detalhes internos do compilador em projetos Go.
O que muda para usuários de TypeScript
Para quem usa TypeScript, a mudança de repositório deve ser quase invisível. O TypeScript 7 continua disponível pelo fluxo normal do npm:
npm install -D typescript
npx tsc
Não é necessário instalar Go nem aprender Go para compilar uma aplicação TypeScript. O pacote oficial instala o novo executável tsc.
A principal mudança ocorre na colaboração com o projeto. Issues, discussões e novos pull requests voltam para microsoft/TypeScript. Pull requests que ficaram abertos no repositório temporário precisam ser recriados no repositório principal.
O merge também não altera o destino do código. O tsc analisa TypeScript, verifica tipos e emite JavaScript quando a configuração solicita emissão. Go fica na implementação interna da ferramenta.
Por que a reunião dos repositórios importa
Um repositório temporário foi útil durante o port. Ele separou uma mudança grande do desenvolvimento normal da implementação anterior. Depois do lançamento, manter dois locais ativos criaria dúvidas sobre issues, contribuições e prioridades.
O PR #63763 encerra essa fase. A preservação do histórico mantém o contexto técnico e o crédito de quem contribuiu durante o port. O diretório tsc agora concentra a implementação que seguirá para o TypeScript 7.1 e versões futuras.
Para a comunidade Go, este é o ponto principal da notícia. O port deixou de ser um projeto paralelo de transição. Ele agora ocupa o centro do desenvolvimento oficial do TypeScript.
Perguntas frequentes
O TypeScript 7 foi escrito em Go?
A implementação do compilador e das ferramentas de linguagem do TypeScript 7 foi portada para Go. A linguagem TypeScript continua sendo TypeScript. Os programas dos usuários continuam tendo JavaScript como destino de compilação.
O TypeScript agora compila código para Go?
Não. Go é a linguagem usada para implementar o compilador tsc e o serviço de linguagem. O compilador continua analisando TypeScript e emitindo JavaScript conforme a configuração do projeto.
O que mudou em 20 de agosto de 2026?
O PR #63763 levou o histórico e o código de microsoft/typescript-go para microsoft/TypeScript. O TypeScript 7.0 já tinha sido lançado em 8 de julho. A mudança de agosto reuniu o desenvolvimento no repositório principal.
Por que a Microsoft escolheu Go para o compilador?
A equipe precisava fazer um port compatível, não um novo compilador do zero. Go combinou com o estilo de funções e estruturas de dados da base existente. Ele também facilitou árvores, grafos, garbage collection, layout de memória e paralelismo nativo.
Quanto o TypeScript 7 ficou mais rápido?
Nos benchmarks oficiais da Microsoft, builds completos ficaram normalmente entre 8x e 12x mais rápidos. O VS Code passou de 125,7 para 10,6 segundos. O Sentry passou de 139,8 para 15,7 segundos, e o Playwright caiu de 12,8 para 1,47 segundo.