Um breve artigo sobre os motivos pelos quais o Node.js não implementou o TypeScript.

As primeiras coisas primeiro

O que se segue é uma explicação do que foi e do que não foi feito no Node.js em relação ao TypeScript.

Este artigo não pretende ser uma crítica à equipe Node.js ou à equipe TypeScript.

Na verdade, é exatamente o oposto.

Acho seriamente que a equipe do Node.js fez a melhor escolha possível ao "implementar" o TypeScript da maneira que fizeram.

O que realmente estou enfatizando aqui é que o Node.js não implementou o TypeScript. Eles apenas adicionaram algum tipo de suporte para isso. Esta é uma distinção crucial que muitas vezes é esquecida nas discussões sobre Node.js e TypeScript.

Nas últimas semanas, contei mais de 50 artigos citados em boletins informativos que li que mencionavam Node.js implementado TypeScript.

Acho que é hora de esclarecer esse ponto de uma vez por todas.

Alerta de spoiler: Node.js não implementou TypeScript.

TypeScript: um breve histórico e alguns dados

Em 2010, a Microsoft lançou o TypeScript, um superconjunto de JavaScript que adiciona digitação estática à linguagem. O TypeScript foi projetado para resolver algumas das deficiências do JavaScript, como a falta de segurança de tipo e a dificuldade de manter grandes bases de código. Desde o seu lançamento, o TypeScript ganhou popularidade entre os desenvolvedores, com muitos projetos adotando-o como linguagem principal.

De acordo com a última pesquisa do State Of JS, o TypeScript está praticamente em todo lugar. 78% dos desenvolvedores usam TypeScript durante pelo menos 50% de seu tempo de desenvolvimento, então não é de admirar que o eco de "Node.js implementou TypeScript" alcançou até os cantos mais profundos da web.

Mas, só para ficar claro, isso não aconteceu. E provavelmente nunca acontecerá.

Os problemas

Existem vários motivos pelos quais o Node.js não implementou o TypeScript. Aqui estão o que considero os dois mais importantes:

Nº 1: TypeScript injeta coisas em tempo de execução.

Você sabia o que um enum se torna em tempo de execução? Um objeto.

E este é apenas um dos - felizmente - poucos exemplos de como o TypeScript injeta coisas em tempo de execução. Isso é um problema para o Node.js porque significaria que o tempo de execução teria que estar ciente dos recursos do TypeScript, o que introduziria muita complexidade e sobrecarga.

Se o Node.js quiser manter sua consistência com o ECMAScript e não ter que lidar com o gerenciamento de dependências pelo resto de sua existência, ele não poderá aceitar o TypeScript como uma dependência na forma atual.

Nº 2: Versionamento Semântico.

TypeScript não segue versionamento semântico (semver).

Node.js, por outro lado, segue semver estritamente e tem três linhas de lançamento diferentes (atualmente, temos 18.x, 20.x, 22.x). Isso significa que alterações significativas podem ser introduzidas em versões secundárias ou de patch, o que pode causar problemas de compatibilidade com o código existente.

Além disso, a quantidade de plataformas suportadas é enorme, por isso não é fácil manter tudo sob controle.

Node.js simplesmente não pode aceitar TypeScript como uma dependência porque isso quebraria sempre. Este é um problema fundamental que impede o Node.js de implementar o TypeScript.

Então, o que eles fizeram?

É aqui que surge a confusão. O Node.js não implementou TypeScript, mas adicionou remoção de tipo sob um sinalizador experimental. Este recurso permite que os desenvolvedores escrevam código TypeScript e compilem-no em JavaScript sem as informações de tipo. Este é um compromisso que permite aos desenvolvedores usar TypeScript em Node.js sem introduzir os problemas mencionados acima.

Quer um exemplo? Aqui você vai:

function sum(a: number, b: number): number {
  return a   b;
}

Esta função, quando compilada com o sinalizador --experimental-strip-types, se tornará:

function sum(a        , b        )         {
  return a   b;
}

Você viu isso? Os tipos desapareceram e foram substituídos por espaços. Mas, por quê?, você pode perguntar. Bem, porque isso preserva as referências dos mapas de origem sem o incômodo de ter um processo de construção separado para eles.

Internamente, isso é feito por meio de um pacote chamado amaro, que envolve swc — uma ferramenta de compilação bem conhecida que faz a remoção real.

É claro que existem limitações, como a incapacidade de usar recursos específicos do TypeScript, como os enums mencionados anteriormente. Mesmo assim, é um grande passo evitar que as pessoas escrevam 135 arquivos de configuração para fazer uma função de soma aceitar dois números e retornar um terceiro.

Ciao,
Miguel.