--- title: "Compilador do TypeScript 7 em Go Entra no Repositório Principal" url: "https://golang.com.br/blog/typescript-7-go-compilador-repositorio-principal/" markdown_url: "https://golang.com.br/blog/typescript-7-go-compilador-repositorio-principal.MD" description: "Microsoft reuniu o compilador do TypeScript 7 em Go no repositório principal. Entenda o PR #63763, os ganhos de 8x a 12x e o impacto." date: "2026-08-20" author: "Golang Brasil" --- # Compilador do TypeScript 7 em Go Entra no Repositório Principal Microsoft reuniu o compilador do TypeScript 7 em Go no repositório principal. Entenda o PR #63763, os ganhos de 8x a 12x e o impacto. **Resposta rápida:** a Microsoft integrou hoje a implementação em Go do TypeScript 7 ao repositório principal [`microsoft/TypeScript`](https://github.com/microsoft/TypeScript). O [PR #63763](https://github.com/microsoft/TypeScript/pull/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](https://github.com/microsoft/typescript-go/discussions/411) 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](/aprenda/concorrencia-go/) e com as primitivas do pacote [`sync`](/blog/sync-mutex-waitgroup-rwmutex-once-go/). 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](https://devblogs.microsoft.com/typescript/announcing-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](/blog/pprof-go-producao/) 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: ```bash 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. --- ## Fontes oficiais - [PR #63763 no repositório microsoft/TypeScript](https://github.com/microsoft/TypeScript/pull/63763) - [Anúncio do TypeScript 7.0](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/) - [Anúncio original do port nativo](https://devblogs.microsoft.com/typescript/typescript-native-port/) - [FAQ oficial: por que Go?](https://github.com/microsoft/typescript-go/discussions/411) - [Status do repositório microsoft/typescript-go](https://github.com/microsoft/typescript-go) - [Aviso oficial da mudança de repositório](https://github.com/microsoft/typescript-go/issues/4918) - [Entrevista da Microsoft com Anders Hejlsberg](https://commandline.microsoft.com/typescript-7-0-anders-hejlsberg-peterman-pod/)