Diagnostics
Plantage de Node + tsx
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 :
[openclaw] Failed to start CLI: TypeError: __name is not a function at createSubsystemLogger (src/logging/subsystem.ts) at <caller> (src/agents/auth-profiles/constants.ts)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
node --versionpnpm installnode --import tsx src/entry.ts statusReproduction minimale isolée (charge uniquement le module figurant dans la trace de pile d’origine) :
node --import tsx scripts/repro/tsx-name-repro.tsLes 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 tsgopour la vérification des types, puis exécutez la sortie compilée au lieu du code source viatsx:bash pnpm tsgonode openclaw.mjs status -
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.