Skip to main content

​
Falha do Node + tsx com “__name is not a function”

​
Status

Resolvido. Essa falha não se reproduz na versão atual do tsx fixada no package.json (4.22.3) nem nas versões atuais do Node. Mantido aqui para o caso de uma futura atualização do tsx/esbuild reintroduzi-la.

​
Sintoma original

A execução dos scripts de desenvolvimento do OpenClaw por meio do tsx falhava na inicialização com:
Os números das linhas foram omitidos; ambos os arquivos mudaram desde a falha original, e as linhas específicas não correspondem mais. Isso surgiu depois que os scripts de desenvolvimento trocaram o Bun pelo tsx (2871657e, 2026-01-06) para tornar o Bun opcional. O caminho equivalente baseado no Bun não falhava. O problema foi observado originalmente no Node v25.3.0 no macOS; considerou-se provável que outras plataformas que executam o Node 25 também fossem afetadas.

​
Causa

O tsx transforma TS/ESM por meio do esbuild com keepNames: true definido diretamente em suas opções de transformação. Essa configuração faz o esbuild envolver declarações nomeadas de funções/classes em uma chamada a um auxiliar __name, para que fn.name seja preservado durante a minificação e o empacotamento. A falha significa que o auxiliar estava ausente ou foi ocultado no ponto da chamada desse módulo na combinação afetada de tsx/Node; assim, __name(...) lançou um erro em vez de retornar o valor envolvido.

​
Verificação atual de reprodução

Reprodução mínima isolada (carrega apenas o módulo do rastreamento de pilha original):
Atualmente, ambos os comandos são concluídos sem erros. Se algum deles voltar a lançar __name is not a function, registre a versão exata do Node, a versão do tsx (node_modules/tsx/package.json) e o rastreamento de pilha completo antes de relatar o problema ao projeto upstream.

​
Soluções alternativas (se a falha retornar)

  • Execute os scripts de desenvolvimento com o Bun em vez de node --import tsx.
  • Execute pnpm tsgo para verificar os tipos e, em seguida, execute a saída compilada em vez do código-fonte por meio do tsx:
  • Tente outra versão do tsx (pnpm add -D tsx@<version> é uma alteração de dependência e requer aprovação de acordo com a política do repositório) para determinar por bisseção se a versão do esbuild incluída por ela reintroduziu o bug.
  • Teste com outra versão principal/secundária do Node para verificar se a falha é específica da versão.

​
Referências

​
Relacionado