Esta página é uma tradução da documentação em inglês. Comandos, identificadores e exemplos permanecem iguais. Runtime 7.24.4 · SDK 2.6.7. Original em inglês

Suporte nativo a TypeScript

Status: ativo no código-fonte; o lançamento do runtime empacotado está pendente Escopo: cadeia de ferramentas e serviço de linguagem do código-fonte no estado atual Última revisão: 2026-09-14 Responsável: mantenedores do AX Code

O AX Code usa o compilador oficial TypeScript 7.0.2, baseado em Go, para as checagens do workspace, a emissão do SDK e o servidor de linguagem embutido de JavaScript e TypeScript. O servidor de linguagem executa direto o executável nativo distribuído com --lsp --stdio. Ele não invoca um executor de registro nem baixa uma versão flutuante do servidor de linguagem. Nenhuma cadeia de ferramentas Go é necessária para usar o AX Code.

Instale as dependências com pnpm install, inclusive as dependências opcionais. O compilador nativo precisa do pacote correspondente de sistema operacional e de CPU. Compilações independentes preparam e verificam esse pacote antes da entrega. Um binário ausente ou incompatível produz um erro acionável, em vez de iniciar em silêncio um servidor em JavaScript.

Compatibilidade da API do compilador

O workspace fixa @typescript/native em npm:typescript@7.0.2 e mantém typescript como alias de npm:@typescript/typescript6@6.0.2 para ferramentas que importam a API legada do compilador em JavaScript. A verificação de tipos e a emissão do SDK usam o compilador nativo. A API de compatibilidade não é o servidor de linguagem padrão.

A ferramenta de framework de Vue, Svelte e Astro usa a própria integração de servidor; a compatibilidade da biblioteca TypeScript não estabelece suporte a plugin de compilador. A transformação JSX do SolidJS continua pelo Babel. Testes de runtime e artefatos emitidos precisam passar de forma independente de uma verificação de tipos bem-sucedida.

Diagnósticos e memória

O TypeScript nativo usa diagnósticos por demanda. O AX Code os solicita quando quem chama pede para esperar os diagnósticos ou coleta o inventário de diagnósticos. Sincronizar um arquivo, sozinho, não espera a verificação de tipos. Edições invalidam resultados em cache que dependem delas; inventários obsoletos, pendentes ou que falharam são informados como parciais ou degradados pela API agregada de diagnósticos. Uma busca bem-sucedida atualiza aquele arquivo. Pedidos de atualização do servidor marcam resultados em cache como obsoletos; o próximo pedido de diagnóstico os atualiza sob demanda. O tráfego de fundo do servidor não renova o tempo de vida ocioso. Edições de arquivo ainda podem atualizar, em segundo plano, documentos pedidos antes. A API bruta de registro atualiza resultados obsoletos dentro de um orçamento limitado de coleta e rejeita inventários incompletos; as ferramentas de edição revelam essa condição sem perder a edição bem-sucedida do arquivo. Os outros servidores de linguagem conservam o comportamento existente de diagnósticos por envio.

Esperas explícitas e sobrepostas de diagnóstico do mesmo arquivo compartilham um pedido apenas dentro da mesma geração do workspace. Pedidos em sequência ainda atualizam; uma mudança de workspace impede reutilizar um pedido mais antigo ainda em curso. Atualizações de fundo e de inventário reavaliam o frescor depois de esperar o bloqueio do documento.

Exclusões e movimentos bem-sucedidos de patch fecham os documentos de origem removidos no serviço de linguagem. Transações de patch que falham conservam o estado do documento. A limpeza tem um prazo compartilhado de dois segundos e pula caminhos recriados por uma operação posterior no mesmo patch. Limpeza incompleta é revelada sem desfazer edições salvas. Se a entrega ao servidor estourar o tempo, os diagnósticos permanecem incompletos até esse cliente reiniciar.

Servidores de linguagem ociosos são recuperados depois de 30 minutos no perfil normal de memória, ou de cinco minutos com AX_CODE_MEMORY_PROFILE=low. A recuperação roda no intervalo já existente de um minuto da checagem de saúde e espera os pedidos ativos e enfileirados assentarem. Os servidores reiniciam sob demanda. AX_CODE_LSP_IDLE_MS substitui a duração ociosa em milissegundos; 0 desativa a recuperação por ociosidade. Valores inválidos usam o padrão do perfil. Estes ajustes não impõem um teto de RAM do processo nem um orçamento para a máquina inteira. O pré-aquecimento especulativo continua opcional.

Recuperar um servidor descarta o inventário de diagnósticos dele. Os resultados agregados permanecem marcados como degradados até que documentos antes abertos tenham sido reabertos e verificados, ou removidos de forma explícita. A API bruta de inventário rejeita cobertura incompleta. O livro de cobertura é limitado a 2,000 caminhos; o excesso permanece, de forma conservadora, incompleto até a instância do projeto ser descartada. Recuperar um servidor vazio não perde cobertura. As ferramentas de edição preservam as alterações salvas e revelam que os diagnósticos estão incompletos. Use uma verificação de tipos do projeto inteiro para estabelecer se o projeto está limpo.

A compilação nativa não garante uma redução específica de memória residente. Compare o mesmo projeto, os mesmos documentos abertos, os mesmos pedidos e o RSS da árvore de processos antes de afirmar algo sobre memória.

Substituição explícita do servidor

Uma configuração confiável já existente de lsp.typescript.command ainda substitui o servidor nativo embutido. Para um servidor legado, instale e fixe o servidor e o SDK TypeScript compatível no projeto, e depois defina command como esse executável instalado com --stdio. Evite comandos npx sem fixação. A substituição é explícita; o AX Code não recua sozinho quando o compilador nativo está indisponível.

Origem: anúncio do TypeScript 7.

Compatibilidade de documento salvo no TypeScript 7.0.2

O servidor nativo 7.0.2 pode devolver um instantâneo de diagnóstico anterior quando o tráfego de observação de arquivos se sobrepõe a edições salvas. O AX Code fecha e reabre os documentos alterados dessa versão exata do servidor antes de pedir diagnósticos. Uma consulta limitada de documento esvazia o fechamento adiado antes de reabrir; as outras consultas esperam essa substituição. Isso envia o documento alterado por inteiro; documentos sem alteração ainda reutilizam pedidos sobrepostos. Outras versões de servidor conservam o modo de sincronização negociado. Uma substituição interrompida permanece incompleta até o servidor de linguagem reiniciar.