Ajouter le `defer` de Go au compilateur TypeScript : un patch pédagogique dans un compilateur écrit en Go

Dev & Code il y a 43 minAjouter aux favoris

Ajouter le `defer` de Go au compilateur TypeScript : un patch pédagogique dans un compilateur écrit en Go
Illustration : Momiji Shirogane

Andrew Healey injecte le mot-clé `defer` - pilier du code Go - directement dans le compilateur TypeScript, désormais écrit en Go. Un cas d'école pour comprendre parser, checker et emitter.

Le point de départ

Depuis que Microsoft a annoncé la réécriture du compilateur TypeScript en Go (le projet « TypeScript Native », qui vise ~10× de vitesse par rapport au tsc historique en TypeScript), le code source du compilateur est devenu un très joli terrain de jeu. Andrew Healey publie sur son blog un article très pédagogique où il ajoute, dans son fork, le mot-clé defer - un des piliers ergonomiques du langage Go - à TypeScript.

Rappel pour ceux qui viennent surtout de la stack JS : en Go, defer planifie une fonction pour qu'elle s'exécute au moment où la fonction englobante retourne. C'est l'équivalent d'un try { … } finally { … } sans le boilerplate, avec l'appel de nettoyage écrit juste à côté de l'appel qui l'a rendu nécessaire :

f, _ := os.Open("file.txt")
defer f.Close() // s'exécutera quand on sort de la fonction
// … reste du code

Le pattern est massivement utilisé pour libérer des ressources (fichiers, mutex, connexions) sans se perdre en imbrications.

Ce que ça décortique

L'intérêt de l'article n'est pas « Go's defer sera dans TypeScript demain » (spoiler : non). C'est de suivre, étape par étape, ce qu'un compilateur moderne fait quand on ajoute un mot-clé. Healey passe par :

  1. Le scanner (lexer) - reconnaître defer comme un token dédié plutôt qu'un identifier ordinaire.
  2. Le parser - décider où defer a le droit d'apparaître dans la grammaire (au niveau statement, oui ; en expression, non).
  3. Le checker (type-checker) - vérifier que ce qui est différé est bien un appel de fonction.
  4. L'emitter - traduire defer en JavaScript, ce qui, dans son cas, revient à envelopper la fonction englobante dans un try/finally et à empiler les callbacks différés dans un tableau exécuté à l'unwind.

Cette dernière étape est celle qui apprend le plus : defer en Go est un vrai mécanisme de langage (implémenté par le runtime), alors qu'en JS on n'a rien de comparable - il faut donc le simuler par un desugaring, avec les compromis que ça implique (perf, exceptions, await, etc.).

Pourquoi c'est intéressant pour nous

Le compilateur TypeScript en Go étant open source, ce genre d'exercice est exactement ce qu'il faut lire pour :

  • Comprendre l'architecture d'un vrai compilateur moderne (pas un jouet universitaire).
  • Voir comment un langage cible (JS) contraint les choix de traduction quand il n'a pas la primitive dont on a besoin.
  • Se familiariser avec le passage AST → typechecking → emission, sur un projet dont on connaît déjà la surface (tsc).

Nous notons au passage que le patch de Healey est proposé en démo, pas en PR upstream - le TC39 n'a jamais retenu defer pour JavaScript standard, et Microsoft ne pousse pas d'extension propriétaire de ce genre dans TypeScript.

À retenir : le vrai gain de la réécriture Go de tsc n'est pas seulement la vitesse - c'est aussi un compilateur dont le code est enfin abordable pour un lecteur qui n'est pas expert en TypeScript avancé. Ce genre de patch pédagogique va se multiplier, et c'est une excellente école.

Ressources, à tester

Article produit par intelligence artificielle, relu sous contrôle éditorial humain.

Notre rédaction
Cet article vous a-t-il été utile ?

7 personnes ont aimé cet article

J'aime
K
Kaito KuroganeRédacteur dev senior
Développeur senior polyvalent, backend Go + frontend TS, contributeur open source.
Partager :
LIVERadio Geek Kitsune
Clique pour écouter, le même son pour tout le monde
0··
// Programme
// toutes les stations
// partager un titre →
Rubriques
Explorer
Informations