Aperçu de TypeScript Native dévoilé

• L’aperçu de tsgo, issu de Corsa, le projet de portage natif en Go du compilateur TypeScript, est publié sur npm
• Annonce de suivi liée au sujet de mars sur TypeScript 10 fois plus rapide
• Par rapport à tsc, il atteint plus de 10 fois plus de vitesse, et prend aussi en charge les fichiers JS basés sur JSX et JSDoc
• Une extension Native Preview pour VS Code a également été lancée, mais l’autocomplétion, la recherche de références, etc. sont encore en cours de développement
• Une nouvelle API native et un serveur de langage basé sur LSP sont aussi en préparation, avec l’introduction du module Node en Rust libsyncrpc
• Certaines fonctionnalités ne sont pas encore implémentées, et il existe des différences nettes entre TypeScript 7 (Corsa) et l’actuelle 5.8 (Strada)

---

Présentation de TypeScript Native Preview

• L’aperçu du projet de portage natif de TypeScript (Corsa), annoncé en mars 2025, est désormais disponible
• Par rapport à la base de code historique en JS (Strada), tsgo, écrit en Go, affiche des gains de performance supérieurs à 10x sur les grands projets grâce au parallélisme et à l’utilisation de mémoire partagée
• tsgo est destiné à terme à remplacer tsc, mais il est pour l’instant distribué sous forme de paquet npm distinct

  npm install -D @typescript/native-preview  
  npx tsgo --project ./src/tsconfig.json  
  

Fonctionnalités de l’extension VS Code

• Lancement de l’extension « TypeScript (Native Preview) » pour VS Code

• Après installation, une activation via la palette de commandes ou les paramètres est nécessaire

  "typescript.experimental.useTsgo": true  
  

• Elle dépend encore de l’extension existante et ses fonctions restent limitées pour le moment, mais des améliorations continues sont prévues

Cycle de publication et feuille de route

• Cet aperçu doit à terme évoluer vers la version finale de TypeScript 7
• Il est diffusé via des builds nightly, avec mises à jour automatiques
• Certaines fonctions ne sont pas encore prises en charge :
  • --build, --declaration, émission vers des cibles inférieures
  • Fonctions d’éditeur : autocomplétion, recherche de références, renommage, etc.

Principales mises à jour

Amélioration de l’exhaustivité de la vérification de types

• La plupart des fonctionnalités de vérification de types ont été portées
• La vérification de types pour JSX et pour JavaScript + JSDoc est désormais aussi prise en charge
• En raison de certains changements intentionnels et de différences dans lib.d.ts, les erreurs peuvent différer

Prise en charge de la vérification de types JSX

• Au départ, JSX pouvait seulement être analysé syntaxiquement, mais la vérification de types complète est désormais prise en charge
• Exemple : sur le projet Sentry, tsc prend 72 secondes, contre 6,7 secondes pour tsgo, soit plus de 10x plus rapide

  tsgo -p . --noEmit --extendedDiagnostics  
  

Vérification de types des fichiers JavaScript

• La fonctionnalité d’analyse des fichiers JS à partir de JSDoc a également été réimplémentée en natif
• Elle a été refactorisée de façon plus moderne et plus cohérente que l’ancienne approche
• Certains anciens patterns pourraient ne plus être reconnus

Fonctions d’éditeur (basées sur LSP)

• Réécriture en cours vers un serveur de langage basé sur LSP à la place de l’ancien TSServer
• La première version fournit l’affichage des erreurs, l’accès à la définition et le survol
• La fonction d’autocomplétion (completion) a également été ajoutée récemment

État d’avancement du développement de l’API

• Une couche d’API basée sur IPC est en cours d’implémentation
• Elle permettra à divers langages de communiquer avec le processus TypeScript
• Pour la communication synchrone depuis Node.js, le module Rust libsyncrpc a été adopté
• La conception de l’API en est encore à ses débuts et les retours sont les bienvenus

Différences avec TypeScript existant

• En raison de certaines différences de configuration, des erreurs peuvent apparaître dans des projets existants :

  • Exemple : --moduleResolution: node → bundler ou nodenext recommandés

    {  
      "compilerOptions": {  
        "module": "preserve",  
        "moduleResolution": "bundler"  
      }  
    }  
    

• Autres différences :

  • l’émission JSX ne peut être que préservée
  • l’émission des déclarations n’est pas prise en charge
  • --build n’est pas pris en charge
  • les services de langage liés aux références de projet ne sont pas encore finalisés

Prochaines étapes

• Objectif : implémenter d’ici la fin de l’année --build ainsi que la majorité des fonctions essentielles de l’éditeur
• L’avancement du développement continuera d’être partagé via le blog et les releases nightly

[riki3]

Je l’utilise en compilant directement le lsp. Le passage à Go rend vraiment perceptible la baisse de consommation des ressources.

[cnaa97]

En ce moment, la mode est d’améliorer les performances simplement en réécrivant du JS en Rust / Go.

[click]

Quand on fait du refactoring, il arrivait assez souvent que l’analyse du code côté tsserver devienne lente au point de figer complètement l’éditeur. J’espère que ça sortira vite pour nous libérer de cette souffrance.