Skip to main content

​
Plantage Node + tsx « __name is not a function »

​
État

Résolu. Ce plantage ne se reproduit pas avec la version actuelle de tsx épinglée dans package.json (4.22.3), ni avec les versions actuelles de Node. Cette page est conservée au cas où une future mise à niveau de tsx/esbuild le réintroduirait.

​
Symptôme d’origine

L’exécution des scripts de développement d’OpenClaw via tsx échouait au démarrage avec :
Les numéros de ligne sont omis ; les deux fichiers ont changé depuis le plantage d’origine et les lignes concernées ne correspondent plus. Ce problème est apparu après le passage des scripts de développement de Bun à tsx (2871657e, 2026-01-06), afin de rendre Bun facultatif. Le chemin équivalent basé sur Bun ne plantait pas. Il a été observé initialement avec Node v25.3.0 sous macOS ; les autres plateformes exécutant Node 25 étaient également considérées comme susceptibles d’être affectées.

​
Cause

tsx transforme TS/ESM au moyen d’esbuild avec keepNames: true codé en dur dans ses options de transformation. Ce paramètre conduit esbuild à encapsuler les déclarations de fonctions/classes nommées dans un appel à une fonction auxiliaire __name, afin que fn.name soit préservé après la minification et le regroupement. Le plantage signifie que la fonction auxiliaire était absente ou masquée au point d’appel de ce module dans la combinaison de versions de tsx/Node concernée ; __name(...) levait donc une exception au lieu de renvoyer la valeur encapsulée.

​
Vérification actuelle de la reproduction

Reproduction minimale isolée (charge uniquement le module figurant dans la trace de pile d’origine) :
Les deux commandes se terminent actuellement sans erreur. Si l’une d’elles lève à nouveau l’erreur __name is not a function, relevez la version exacte de Node, la version de tsx (node_modules/tsx/package.json) et la trace de pile complète avant de signaler le problème en amont.

​
Solutions de contournement (si le plantage réapparaît)

  • Exécutez les scripts de développement avec Bun au lieu de node --import tsx.
  • Exécutez pnpm tsgo pour la vérification des types, puis exécutez la sortie compilée au lieu du code source via tsx :
  • Essayez une autre version de tsx (pnpm add -D tsx@<version> constitue une modification de dépendance et nécessite une approbation conformément à la politique du dépôt) afin de déterminer par dichotomie si la version d’esbuild qu’elle intègre a réintroduit le bogue.
  • Testez avec une autre version majeure/mineure de Node pour déterminer si l’échec est propre à une version.

​
Références

​
Pages connexes