Node.js adiciona suporte experimental a TypeScript

Módulo: adição de --experimental-strip-types

• É possível executar arquivos TypeScript no Node.js

  • Ao definir a flag --experimental-strip-types, é possível executar arquivos TypeScript
  • O Node.js converte o código-fonte TypeScript em código-fonte JavaScript
  • Durante o processo de conversão, não é feita verificação de tipos; os tipos são removidos

• Motivação

  • É importante permitir a execução de arquivos TypeScript sem dependências externas ou loaders
  • Querem que os usuários possam executar node foo.ts

• O significado de remover tipos

  • Remover tipos significa eliminar todos os tipos e converter a entrada em um módulo JavaScript
  • Exemplo: const foo: string = "foo"; é convertido em const foo = "foo";

• Motivo da escolha do @swc/wasm-typescript

  • Pela simplicidade
  • Outras ferramentas exigem adicionar Rust ou Go, mas o @swc/wasm-typescript precisa apenas de um pacote pequeno com arquivos wasm e js
  • Também é usado no Deno, o que o torna confiável

• Limitações

  • Recursos exclusivos do TypeScript, como enum e namespaces, não são convertidos
  • Imports sem extensão não são suportados

• Planos futuros

  • Pode vir a ser implementado na camada nativa
  • Pode receber suporte a source maps

Resumo do GN⁺

• Explica um novo recurso que permite executar arquivos TypeScript no Node.js
• Permite converter e executar arquivos TypeScript como JavaScript, sem realizar verificação de tipos
• Isso simplifica o ambiente de desenvolvimento ao permitir que usuários executem arquivos TypeScript sem dependências externas
• Esse recurso foi implementado com @swc/wasm-typescript, e também está sendo considerada uma implementação futura na camada nativa
• Pode ser útil para projetos que usam TypeScript e JavaScript de forma combinada.

[GN⁺]

Comentários no Hacker News

• Remover os tipos do TypeScript não é possível sem a gramática do TypeScript. A remoção de tipos não é uma tarefa no nível de tokens, e a gramática do TypeScript continua mudando

  • Por exemplo, foo < bar & baz > ( x ) era interpretado de forma diferente no TypeScript 1.5
  • Para usar novos recursos do TypeScript, seria preciso compilar para JS ou manter a versão do Node sempre atualizada
  • Para quem usa releases LTS do Node, isso pode ser uma concessão difícil

• Se o Node.js puder executar arquivos TypeScript diretamente, o compilador TypeScript não precisaria remover os tipos e convertê-los para JavaScript

  • Isso é semelhante ao caso do Python
  • No Python, existem vários verificadores de tipos, e todos usam a mesma sintaxe de type hints, mas aplicam significados diferentes
  • No JavaScript, o TypeScript acabou se tornando o único verificador de tipos realmente popular
  • No Python, algumas pessoas usam type hints como se fossem comentários
  • Se o Node.js passar a oferecer suporte para ignorar tipos, isso também pode acontecer no JavaScript

• Fico curioso para saber como o ecossistema do NPM reagiria se esse recurso se tornasse o padrão

  • Ao publicar módulos no NPM, fica a dúvida se ainda faria sentido continuar gerando versões CJS e EJS, ou se bastaria adicionar engine: nodejs >= 25 no package.json e pular a etapa de build
  • Pessoalmente, espero que módulos NPM escritos em TS deixem de fornecer dist/.cjs
  • Pular a etapa de build seria algo muito tentador para contribuidores do NPM
  • Isso pode causar um efeito em cadeia no ecossistema do NPM
  • Se o Node.js oferecer esse recurso sem flag experimental, é de se esperar que todos os consumidores aceitem arquivos TS
  • Isso pode até forçar Firefox e Safari a também aceitarem arquivos TS
  • Pessoalmente, acho ótimo que compiladores JS descartem anotações de tipo do TS
  • Se o Node aceitar arquivos .ts, a etapa de transcompilação pode desaparecer

• Seria um grande ganho se o Node pudesse inspecionar tipos em JS

  • No Python, existem ferramentas como pydantic, que inspecionam tipos e geram validações
  • Isso permite validação de tipos, validação de dados em tempo de execução, geração de APIs e geração de documentação de API com uma única notação padrão
  • Hoje, em JS, são necessárias ferramentas como zod

• A experiência de desenvolvimento (DX) do Bun é sem precedentes nessa área, e cobre a maioria dos casos de uso

  • No Node, não dá para configurar importações sem exigir extensões, nem fazer o tsc adicionar extensões .js automaticamente
  • O suporte nativo a TypeScript pode resolver isso, mas será difícil alcançar a experiência de uso ou o desempenho do Bun

• Gosto muito de TypeScript e venho desejando um runtime de TypeScript há muito tempo

  • Saí do Java porque queria um sistema de tipos com mais recursos e tipagem gradual
  • Apesar das desvantagens do ecossistema npm, usar bibliotecas é menos penoso e mais divertido
  • Rust está em outra parte do espectro de linguagens, mas oferece uma sensação parecida
  • JIT era o termo errado; eu queria me referir às diferenças de tempo de inicialização e de execução entre JVM e V8

• Meu recurso favorito do deno está chegando diretamente ao Node

  • Estou muito animado por poder remover tipos sem instalar esbuild
  • Ultimamente tenho preferido Python, mas TypeScript é melhor em tipos do que Python
  • Scripts grandes se beneficiam muito mais quando têm tipos

• Foi um mês muito importante para o Node

  • No v22.5.0, adicionou node:sqlite, e agora está recebendo suporte a TypeScript
  • Gosto da direção que o Node está tomando

• Sou o autor do PR, AMA

• Comecei a usar Node.js para trabalho de backend há muito tempo, e ele oferecia muitas vantagens sobre PHP

  • O Node era meio incômodo e precisava ser montado peça por peça para virar a linguagem que eu queria
  • Comecei a usar Golang, e programar ficou mais fácil graças à segurança de tipos
  • TypeScript é uma boa opção, mas continua sendo apenas mais um adicional
  • A grande vantagem de usar Node é a velocidade de prototipagem, e usar TypeScript pode acabar anulando essa vantagem