Node.js passa a oferecer suporte à execução de arquivos TypeScript sem configuração adicional

• O Node.js foi aprimorado para executar arquivos TypeScript diretamente
• Agora é possível executar arquivos .ts imediatamente, sem configuração adicional nem transpilações
• Os desenvolvedores podem aumentar a eficiência do trabalho sem tsconfig.json nem instalação de bundlers separados
• Esse recurso foi oficialmente incorporado a partir da versão v22.18.0 (LTS) do Node.js
• Espera-se como resultado uma redução da barreira entre o desenvolvimento em JavaScript e TypeScript

---

Suporte do Node.js à execução direta de TypeScript

• O Node.js introduziu recentemente, na versão v22.18.0 (LTS), um recurso que permite executar diretamente arquivos TypeScript (.ts) sem configurações ou ferramentas separadas
• Antes, para executar código TypeScript, eram necessários transpiladores externos ou bundlers como ts-node, esbuild e Babel; agora, o próprio Node.js reconhece e executa código TypeScript sem essas ferramentas
• Com esse recurso, os desenvolvedores podem executar arquivos .ts diretamente no Node.js sem arquivo de configuração tsconfig.json nem bibliotecas adicionais
• Em prototipagem, desenvolvimento experimental e execução de scripts, a produtividade e a praticidade no desenvolvimento aumentam significativamente
• Espera-se também maior integração entre projetos JavaScript e TypeScript, além de uma redução da barreira de entrada para novos desenvolvedores

Outras mudanças dignas de nota

• esm: implementação de import.meta.main
• fs: melhoria no processamento de eventos do fs com base em AsyncIterator
• permission: suporte ao envio de flags do modelo de permissões ao executar subprocessos
• sqlite: adição da opção readBigInts
• src/permission: suporte a permission.has(addon)
• url: adição da API fileURLToPathBuffer
• watch: adição da flag --watch-kill-signal
• worker: aprimoramento do objeto Worker como async disposable

Atualizações relacionadas a commits e documentação

• Inclui remoção de código desnecessário, organização do ambiente de build e da toolchain, além do upgrade para npm 10.9.3
• Correções em indicadores detalhados de estabilidade e números de RFC na documentação, como globals.md, child_process.md e http2
• Inclusão de vários testes e aplicação de correções de bugs

Arquivos de distribuição

• Instaladores e binários disponíveis para Windows, macOS (Intel/Apple Silicon) e Linux (x64, ARM, PPC, s390x, AIX)
• O código-fonte e os arquivos completos da release podem ser baixados na página oficial de distribuição do Node.js
• A documentação da API foi atualizada com base na v22.18.0

[aliveornot]

Até que enfim... espero que isso se consolide logo.

[tested]

Parece que pode ser bom para executar scripts simples, mas para projetos reais há muitas limitações, então não parece algo que eu vá usar muito.

Também é preciso acertar a extensão e o caminho por causa dos erros ERR_MODULE_NOT_FOUND/ERR_UNSUPPORTED_DIR_IMPORT,
e recursos como o NestJS, que precisam de suporte à compilação do TypeScript com a configuração "emitDecoratorMetadata", acabam não podendo ser usados, então...

[kimjeongwonn]

O --experimental-strip-types passa a ser aplicado por padrão?

[click]

De qualquer forma, eu não uso enum, então, pelos meus critérios, só o comportamento de remover tipos já foi mais do que suficiente para rodar bem.

[crawler]

Vai ficar muito mais prático!

[honglu]

Não dá pra segurar o joinha.

Mesmo achando que já era bom o suficiente com a flag --no-experimental-strip-types.

Parece ainda melhor.

[GN⁺]

Comentários no Hacker News

• Com node:test no Node.js, acho que agora o Node.js é uma escolha padrão convincente na maioria dos casos. Rodar com tsx já era um grande ganho de qualidade de vida, mas ainda não era perfeito. A asserção de tipos em runtime na borda está sendo em grande parte resolvida com ferramentas como zod, ts-rest e trpc, e hoje em dia o desenvolvimento full-stack em TypeScript ficou realmente fácil
  • É verdade mesmo. Em 2025, finalmente o ecossistema do Node ficou utilizável só com a configuração padrão. Módulos ESM funcionam naturalmente tanto no Node quanto no TypeScript, o Node consegue executar arquivos .ts diretamente e ainda traz um runner de testes embutido de bom nível (com suporte a --watch). Os pacotes embutidos também estão melhorando. No caso de node:fs/promises, por exemplo, graças ao top-level await ficou bem mais fácil fazer trabalhos assíncronos em loop. Demorou para convencer todo mundo a adotar uma abordagem prática, mas agora a experiência está realmente agradável
  • Sou totalmente a favor de o Node oferecer suporte direto a TypeScript. O vitest hoje facilita muita coisa, mas eu já perdi tempo demais só configurando ambiente de testes para arquivos .ts. Acho que trpc e ts-rest resolvem problemas completamente diferentes. Dá para usar os dois, mas em produção evito trpc porque não consigo ter controle direto sobre as URLs da API, nem gerenciar e descontinuar URLs antigas de forma natural. No caso de ts-rest, normalmente prefiro compartilhar zod e os tipos diretamente para gerenciar eu mesmo os pares de request/response da API. E sempre me incomoda ver -rest no nome de algo que é claramente uma ferramenta de RPC
  • Vou acompanhar para ver se a Sveltr vai migrar o codebase de volta para TypeScript no futuro
  • Fiquei curioso se isso executa tsx. Mesmo removendo os tipos, JSX ainda precisa ser transformado em JavaScript, então queria entender essa parte
  • Eu mudei para Python recentemente. Estou muito mais satisfeito porque quase tudo já vem embutido, então não preciso depurar vários problemas estranhos de um sistema inacabado
• Fiquei muito impressionado com a evolução que o Node mostrou nos últimos anos. Foi ótimo ver Deno e Bun pressionando o Node a fazer melhorias mais focadas e significativas. Durante um tempo ele tinha ficado estagnado
  • Quais melhorias recentes houve no Node? A última que considerei realmente relevante foi o suporte oficial a import/export (não sei se ainda precisa do hack com .mjs). Faz um tempo que estou afastado do ecossistema, então queria saber o que mudou depois disso
  • Não sei se foi bem assim. Pelos projetos em que participei, Deno e Bun não faziam nenhuma falta. Na prática, o que realmente importa são os releases LTS do Node, e até projetos novos ainda usam Node 20
• Acho uma pena que TypeScript não seja aceito dentro de node_modules (relacionado: documentação oficial do node.js). Então fico me perguntando como ficam as dependências de projeto. Escrevi uma biblioteca de modelos de dados em TypeScript e queria importá-la no meu app ainda em TypeScript. Queria saber se essa regra vale só para pacotes npm ou para toda e qualquer dependência. Há uma oportunidade aí. Eu criei um runtime em Go para executar TypeScript (mais exatamente JS em geral), e o sobek usado pela equipe do Grafana talvez só precisasse ganhar a função de remover tipos. Se surgir um runtime que realmente adote TypeScript como padrão, sinto que isso pode ser a verdadeira inovação além do Node.js. Sem transpiler, sem typescript-go, sem Rust (embora Rust ainda tenha seu charme 😉), bastaria um sistema com um bom parser que acompanhe source maps e tipos em modo de depuração. De qualquer forma, ficam meu reconhecimento e agradecimento ao time do Node e a todos os contribuidores. Como o Node virou padrão, parece que todos nós vamos atrás dele. A API de embedding também é simples e agradável de usar, o que facilita até para gerar executáveis standalone
  • Já deixei o mesmo comentário antes (referência). Tem a parte que diz “para desencorajar a publicação de pacotes escritos em TypeScript no npm”, e eu também tentei isso com pacote privado, mas não funcionou; o Node nem liga para o campo private
  • Acho que pacotes deveriam ser sempre compilados para JavaScript antes de serem publicados no npm. Não vejo motivo para subir TypeScript puro no npm
• Issue relacionada Também acho uma pena não haver suporte a remoção de tipos dentro de node_modules
  • Metade do motivo de eu esperar esse recurso era exatamente isso. Eu queria escrever bibliotecas em TypeScript, fazer a checagem de tipos só no CI/CD e depois importar direto no Node.js
  • Acho que foi a decisão correta. O TypeScript sofre breaking changes com certa frequência. Enquanto não houver padronização, acho melhor continuar assim
• Não sou alguém que usa muito JS/TS, mas fico pensando se não seria melhor simplesmente usar Bun. Nem todo projeto começa do zero, claro, mas no geral Bun me parece um runtime melhor. Já executa TS desde o início, resolve dependências bem mais rápido e a usabilidade é excelente. Pessoalmente migrei vários projetos antigos de Node para Bun e, desde o lançamento do Bun, quase não uso mais Node. Se eu estiver deixando passar algo, adoraria saber
  • Usei só Node por quase 8 anos e recentemente migrei para Deno. Essa transição também não foi fácil, e meu medo não era exatamente algo deixar de funcionar agora, mas nunca saber quando algo quebraria. O Node com certeza tem várias limitações, mas ainda é o padrão de fato da indústria. O ecossistema JS em si já é caótico, então muita gente está cansada de mais uma nova build tool, bundler ou runtime. Não acho que o Bun ainda tenha acumulado estabilidade ou suporte suficientes para se tornar convincente. Já tive experiência de passar dias resolvendo problema causado por um update menor do TS
  • Eu não gosto muito de correr atrás da última moda. NodeJS é o runtime com melhor suporte no ecossistema JS. Acho muito melhor seguir a opção padrão. Sou do tipo que prefere tecnologias “sem graça”
  • Tentei fazer a migração completa várias vezes desde o lançamento do Bun, mas sempre bato em algum problema inevitável quando chego em uns 90%. Na última tentativa, algumas bibliotecas não funcionavam porque certas funções napi não estavam implementadas, e também lembro de problemas como a opção recursive em opendir sendo ignorada. Estou torcendo para o Bun alcançar isso, mas ainda não parece pronto para uso profissional em projetos grandes. Os recursos exclusivos do Bun também parecem legais à primeira vista, mas na prática deixam a desejar. A documentação também não tem a mesma qualidade da do Node.js
  • Estes são problemas de compatibilidade que enfrentei ao tentar substituir Node por Bun.
• localAddress ignorado em conexões TCP
• Incompatibilidade com a API de módulos do Node (exemplo: o projeto spamscanner não funciona)
• Problemas de race envolvendo EventEmitter (parcialmente resolvidos com eventemitter2)
• O servidor de desenvolvimento do Svelte com Vite às vezes travava, então eu precisava apagar node_modules e reinstalar

  • Já usei os recursos de TS e runner de testes do próprio Node, mas ainda não estão no nível do Bun. Por enquanto, quando preciso desse tipo de funcionalidade, continuo usando Bun. No ecossistema Node aprendi que, em vez de apostar tudo em uma única solução, é melhor combinar ferramentas especializadas.

    • Bun.js: uso como runtime Node, para execução de TS e testes. Já experimentei várias opções como TSX, TS-Node e o próprio Node

    • NPM: uso para executar scripts de tooling

    • PNPM: uso para instalar dependências. (Na minha opinião é o melhor entre npm, yarn e bun)

    • Biome.js: uso para linting. É melhor do que qualquer outra ferramenta de lint que já usei

• O fato de essa melhoria ser apenas “type stripping” é realmente ótimo, porque não precisa de source maps e, em produção, acaba tendo custo zero de verdade. O time do Node mandou muito bem
• A função de remoção de tipos (import { stripTypeScriptTypes } from 'node:module') também está exposta. Em apps web simples sem dependências de frontend, dá para fazer tudo em TypeScript e, ao servir os scripts de frontend, apenas remover os tipos (projeto de exemplo)
• Graças a essa mudança, nossa empresa finalmente conseguiu migrar para TypeScript. Convertimos vários serviços para TS de uma vez, e alguns ainda estão em andamento. Foi um grande ganho
• Pelo jeito, o funcionamento é apenas remover as informações de tipo. Ou seja, isso elimina uma etapa de transpile, mas não melhora a segurança em si
  • Um dos principais objetivos de design do TypeScript é que, ao remover apenas a sintaxe relacionada a tipos, o resultado seja um arquivo JavaScript válido. O compilador TS não gera código (diferente de PureScript, por exemplo). A checagem estática é feita por um verificador de tipos como o tsc, e a informação de tipo é removida. Em Python, as anotações de tipo também são ignoradas em runtime, e em Java parte das informações de tipo, como alguns genéricos, também desaparece no bytecode
  • Dizer que “isso no máximo elimina uma etapa de transpile e não melhora a segurança” é um pouco enganoso. Executar TS diretamente no Node não aumenta a segurança de type checking por si só, mas a checagem de tipos pode ser feita separadamente no editor ou em várias outras ferramentas. Ao suportar execução direta de TS, o Node reduz bastante a barreira de entrada para usar TS e, indiretamente, ajuda na segurança de tipos
  • O TypeScript nunca prometeu garantir melhoria de segurança. É um mal-entendido comum. TS não tinha modo nem informação de runtime, então, se você não rodar o verificador de tipos, ele executa mesmo com erros graves de tipo. Em termos estritos, o TypeScript é mais próximo de um linter
  • Acho extremamente conveniente poder executar scripts direto, sem build/transpile. Se eu precisar de typecheck, rodar tsc separadamente funciona muito bem para mim
  • Já usamos no projeto uma configuração com tsx que permite exatamente isso: executar sem build/transpile. É muito útil durante o desenvolvimento. Com tsx --watch, subimos o servidor direto do código TS e ele reinicia automaticamente quando há mudanças. Daqui para frente, talvez dê para montar algo parecido só com nodemon e recursos embutidos do Node. Para fazer type checking em runtime, seria preciso suporte no nível do V8, e isso seria quase uma reescrita completa
• Na prática, isso não executa TypeScript completo, e sim apenas um subconjunto. O título pode soar exagerado. Há o risco de essa mudança incentivar o uso de TS só como linter, e vários recursos poderosos da linguagem que não podem ser implementados apenas com remoção de tipos podem acabar sendo deixados de lado
  • Fiquei curioso sobre quais recursos do TS não podem ser tratados só com stripping. Fora enum, que casos reais de uso existem?