Cette page est traduite de la documentation anglaise. Les commandes, identifiants et exemples sont inchangés. Runtime 7.24.4 · SDK 2.6.7. Source anglaise

Prise en charge native de TypeScript

Statut : actif dans les sources ; publication du runtime empaqueté en attente Portée : chaîne d’outils sources et service de langage, état actuel Dernière revue : 2026-09-14 Responsable : mainteneurs d’AX Code

AX Code utilise le compilateur officiel TypeScript 7.0.2, fondé sur Go, pour les contrôles de l’espace de travail, l’émission du SDK et son serveur de langage JavaScript/TypeScript intégré. Le serveur de langage exécute directement l’exécutable natif livré avec --lsp --stdio. Il n’invoque pas un lanceur de registre et ne télécharge pas une version flottante du serveur de langage. Aucune chaîne d’outils Go n’est nécessaire pour utiliser AX Code.

Installez les dépendances avec pnpm install, y compris les dépendances facultatives. Le compilateur natif a besoin du paquet OS/CPU correspondant. Les constructions autonomes préparent et vérifient ce paquet avant la livraison. Un binaire absent ou incompatible produit une erreur exploitable, au lieu de démarrer en silence un serveur JavaScript.

Compatibilité de l'API du compilateur

L’espace de travail épingle @typescript/native sur npm:typescript@7.0.2 et conserve typescript en alias de npm:@typescript/typescript6@6.0.2 pour les outils qui importent l’API Compiler JavaScript héritée. Les contrôles de types et l’émission du SDK utilisent le compilateur natif. L’API de compatibilité n’est pas le serveur de langage par défaut.

L’outillage de framework pour Vue, Svelte et Astro utilise sa propre intégration de serveur ; la compatibilité de la bibliothèque TypeScript n’établit pas la prise en charge des greffons de compilateur. La transformation JSX de SolidJS continue de passer par Babel. Les tests d’exécution et les artefacts émis doivent réussir indépendamment d’un contrôle de types réussi.

Diagnostics et mémoire

TypeScript natif utilise des diagnostics en mode pull. AX Code les demande lorsqu’un appelant demande d’attendre les diagnostics ou rassemble l’inventaire des diagnostics. Synchroniser un fichier seul n’attend pas le contrôle de types. Les modifications invalident les résultats en cache qui en dépendent ; les inventaires périmés, en attente ou en échec sont signalés comme partiels ou dégradés par l’API de diagnostics agrégés. Un tirage réussi rafraîchit ce fichier. Les demandes de rafraîchissement du serveur marquent les résultats en cache comme périmés ; la demande de diagnostic suivante les rafraîchit à la demande. Le trafic de serveur en arrière-plan ne renouvelle pas la durée de vie d’inactivité. Les modifications de fichiers peuvent encore rafraîchir en arrière-plan des documents déjà demandés. L’API d’enregistrement brut rafraîchit les résultats périmés dans un budget de collecte borné et rejette les inventaires incomplets ; les outils d’édition signalent cette condition sans perdre la modification de fichier réussie. Les autres serveurs de langage conservent leur comportement existant de diagnostics en mode push.

Des attentes de diagnostic explicites qui se chevauchent, pour le même fichier, ne partagent une requête qu’au sein de la même génération d’espace de travail. Les requêtes successives rafraîchissent encore ; un changement d’espace de travail empêche de réutiliser une requête plus ancienne encore en cours. Les rafraîchissements d’arrière-plan et d’inventaire revérifient la fraîcheur après avoir attendu un verrou de document.

Les suppressions et déplacements de correctif réussis ferment les documents sources retirés dans le service de langage. Les transactions de correctif échouées conservent l’état de leurs documents. Le nettoyage a une échéance partagée de deux secondes et ignore les chemins recréés par une opération ultérieure du même correctif. Un nettoyage incomplet est signalé sans annuler les modifications enregistrées. Si la livraison au serveur expire, les diagnostics restent incomplets jusqu’au redémarrage de ce client.

Les serveurs de langage inactifs sont récupérés après 30 minutes dans le profil mémoire normal, ou après cinq minutes avec AX_CODE_MEMORY_PROFILE=low. La récupération s’exécute sur l’intervalle existant de contrôle de santé d’une minute et attend que les requêtes actives et en file se stabilisent. Les serveurs redémarrent à la demande. AX_CODE_LSP_IDLE_MS remplace la durée d’inactivité en millisecondes ; 0 désactive la récupération d’inactivité. Les valeurs invalides utilisent le défaut du profil. Ces réglages n’imposent ni un plafond de RAM du processus ni un budget à l’échelle de la machine. Le préchauffage spéculatif reste sur activation.

Récupérer un serveur abandonne son inventaire de diagnostics. Les résultats agrégés restent marqués dégradés jusqu’à ce que les documents ouverts auparavant aient été rouverts et contrôlés, ou retirés explicitement. L’API d’inventaire brut rejette une couverture incomplète. Le registre de couverture est limité à 2 000 chemins ; le dépassement reste prudemment incomplet jusqu’à la destruction de l’instance du projet. Récupérer un serveur vide ne perd aucune couverture. Les outils d’édition conservent les changements enregistrés et signalent que les diagnostics sont incomplets. Utilisez un contrôle de types complet du projet pour établir si le projet est propre.

La compilation native ne garantit pas une réduction particulière de la mémoire résidente. Comparez le même projet, les mêmes documents ouverts, les mêmes requêtes et le RSS du même arbre de processus avant d’affirmer un gain de mémoire.

Remplacement explicite du serveur

Une configuration lsp.typescript.command de confiance déjà présente remplace encore le serveur natif intégré. Pour un serveur hérité, installez et épinglez dans le projet le serveur et son SDK TypeScript compatible, puis définissez command sur cet exécutable installé avec --stdio. Évitez les commandes npx non épinglées. Le remplacement est explicite ; AX Code ne bascule pas automatiquement lorsque le compilateur natif est indisponible.

Amont : annonce de TypeScript 7.

Compatibilité des documents enregistrés avec TypeScript 7.0.2

Le serveur natif 7.0.2 peut renvoyer un instantané de diagnostic antérieur lorsque le trafic de surveillance de fichiers chevauche des modifications enregistrées. AX Code ferme et rouvre les documents changés pour cette version exacte du serveur avant de demander les diagnostics. Une requête de document bornée vide la fermeture différée avant la réouverture ; les autres requêtes attendent ce remplacement. Cela envoie le document changé en entier ; les documents inchangés réutilisent encore les requêtes qui se chevauchent. Les autres versions de serveur conservent leur mode de synchronisation négocié. Un remplacement interrompu reste incomplet jusqu’au redémarrage du serveur de langage.