Annonce de TypeScript 7.0

 (devblogs.microsoft.com)
4 points par GN⁺ 2 시간 전 | 2 commentaires | Partager sur WhatsApp
  • TypeScript 7.0 est une version qui porte la toolchain vers du code natif basé sur Go, avec en général une accélération de 8 à 12 fois sur les builds complets de grands projets
  • Le nouveau tsc s’installe comme auparavant via le package npm typescript, et la prise en charge dans les éditeurs fonctionne via un serveur de langage basé sur LSP dans VS Code, Visual Studio, WebStorm, etc.
  • Sur des bases de code comme vscode, sentry, bluesky, playwright et tldraw, le temps de build a fortement baissé, et dans certains environnements, l’utilisation mémoire totale a aussi diminué
  • TypeScript 7.0 ne dispose pas encore d’une API de programmation stable, donc les outils qui embarquent TypeScript, comme typescript-eslint, Vue, MDX, Astro, Svelte ou la vérification de types des templates Angular, doivent continuer à fonctionner en parallèle avec TypeScript 6.0
  • De nouvelles valeurs par défaut et des options supprimées sont à prévoir, donc appliquer d’abord les changements de TypeScript 6.0 facilite la transition, et une nouvelle API est prévue avec TypeScript 7.1

TypeScript natif basé sur Go

  • TypeScript 7.0 est un portage natif de la toolchain TypeScript, avec une nouvelle base de code écrite en Go
  • Le portage a été réalisé en conservant autant que possible la structure et la logique de l’ancienne base de code afin d’assurer la cohérence des résultats et la compatibilité entre les deux compilateurs
  • La nouvelle base de code obtient en général des builds complets 8 à 12 fois plus rapides grâce à la vitesse du code natif, au multithreading basé sur mémoire partagée et à diverses optimisations
  • L’installation reste possible via npm, comme avant
npm install -D typescript
  • Après l’installation, le nouvel exécutable tsc est disponible dans le workspace et peut être lancé avec npx tsc

Boucle de feedback plus courte

  • TypeScript intervient à plusieurs étapes du développement, comme le chargement dans l’éditeur, la recherche de toutes les références, l’autocomplétion, les diagnostics, tsc et le mode --watch
  • TypeScript 7 réduit les temps d’attente tout au long de ce processus et raccourcit la boucle de feedback
  • Dans la base de code de VS Code, le temps nécessaire pour voir apparaître la première erreur à l’ouverture d’un fichier contenant une erreur est passé d’environ 17,5 secondes à moins de 1,3 seconde, soit plus de 13 fois plus rapide
  • Le support éditeur repose sur LSP, et le nouveau serveur de langage exploite le multithreading pour traiter rapidement les requêtes simultanées
  • Les utilisateurs de VS Code peuvent installer l’extension dédiée à TypeScript 7, et la prise en charge de TypeScript 7 devrait être intégrée directement à VS Code dans les prochaines semaines
  • Les versions récentes de Visual Studio activent automatiquement TypeScript 7 selon le workspace

Performances de build et mémoire

  • Voici les temps de build complet comparant TypeScript 6 et 7 sur de grandes bases de code open source
Base de code TypeScript 6 TypeScript 7 Gain de vitesse
vscode 125.7 s 10.6 s 11.9×
sentry 139.8 s 15.7 s 8.9×
bluesky 24.3 s 2.8 s 8.7×
playwright 12.8 s 1.47 s 8.7×
tldraw 11.2 s 1.46 s 7.7×
  • Sur ces mêmes builds, TypeScript 7 affichait aussi globalement une utilisation mémoire totale plus faible
Base de code TypeScript 6 TypeScript 7 Évolution mémoire
vscode 5.2GB 4.2GB -18%
sentry 4.9GB 4.6GB -6%
bluesky 1.8GB 1.3GB -26%
playwright 1.0GB 0.9GB -11%
tldraw 0.6GB 0.5GB -15%

Validation sur des bases de code réelles et retours des équipes

  • Le projet TypeScript exécute des dizaines de milliers de tests accumulés sur plus de 10 ans pour chaque commit sur la branche main
  • En plus de ces tests, TypeScript 7 a été validé sur des bases de code réelles par de grandes équipes internes et externes
  • En interne chez Microsoft, les équipes Loop, Office, PowerBI, Teams et Xbox ont validé TypeScript 7
  • En externe, Bloomberg, Canva, Figma, Google, Lattice, Linear, Miro, Notion, Sentry, Slack, Vanta, Vercel, VoidZero et d’autres l’ont testé sur leurs bases de code et ont fourni des retours
  • Le nouveau serveur de langage réduit de plus de 80 % les commandes de serveur de langage en échec et de plus de 60 % les crashs serveur par rapport à TypeScript 6.0
  • Parmi les retours d’équipes réelles, on peut citer les cas suivants
    • Slack indique que le temps de merge queue a baissé de 40 % avec TypeScript 7, et que le temps de vérification de types en CI est passé d’environ 7,5 minutes à 1,25 minute
    • Vanta a observé jusqu’à 9 fois plus de vitesse de build sur l’un de ses grands projets
    • L’équipe Microsoft News Services économise 400 heures par mois d’attente sur les builds CI
    • Canva indique que le temps nécessaire pour voir la première erreur dans l’éditeur est passé d’environ 58 secondes à 4,8 secondes

Exécution en parallèle avec TypeScript 6.0

  • TypeScript 7.0 n’inclut pas encore d’API
  • Une nouvelle API, différente, est prévue pour TypeScript 7.1
  • D’ici là, il est possible d’exécuter TypeScript 6.0 et 7.0 en parallèle pour les outils qui ont besoin d’un accès programmatique au compilateur
  • Le nouveau package de compatibilité @typescript/typescript6 fournit l’exécutable tsc6 et réexporte l’API de TypeScript 6.0
  • Pour les outils comme typescript-eslint qui importent directement typescript comme peer dependency, l’usage d’un alias npm est recommandé
npm install -D typescript@npm:@typescript/typescript6
  • Pour utiliser ensemble l’API TypeScript 6 et le tsc de TypeScript 7, on peut définir un alias comme suit
{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}
  • L’ancien package @typescript/native-preview fournissait jusqu’ici les builds nightly de la nouvelle base de code de TypeScript 7, avec plus de 8,5 millions de téléchargements hebdomadaires
  • À l’avenir, les builds nightly reprendront via le tag next du package standard typescript
npm install -D typescript@next

Options de contrôle de la parallélisation

  • TypeScript 7.0 exécute en parallèle plusieurs étapes comme le parsing, la vérification de types et l’emit

  • Le parsing et l’emit sont faciles à exécuter indépendamment fichier par fichier, ce qui permet de bien passer à l’échelle sur de grandes bases de code avec relativement peu d’overhead

  • Les nouveaux flags expérimentaux --checkers, --builders, --singleThreaded permettent d’ajuster le comportement de la parallélisation

  • --checkers

    • TypeScript 7.0 crée un nombre fixe de workers de vérification de types et répartit toujours le travail de la même manière pour un même ensemble de fichiers d’entrée, afin de produire des résultats identiques
    • Le nombre par défaut de workers de vérification de types est de 4, et peut être ajusté avec --checkers
    • Voici les résultats obtenus sur la même machine avec --checkers 8
    Base de code TypeScript 6 TypeScript 7 --checkers 8 Gain de vitesse
    vscode 125.7 s 7.51 s 16.7×
    sentry 139.8 s 12.08 s 11.6×
    bluesky 24.3 s 2.01 s 12.1×
    playwright 12.8 s 1.16 s 11×
    tldraw 11.2 s 1.06 s 10.6×

  • Augmenter --checkers peut accélérer la build en exploitant davantage de cœurs CPU, mais cela s’accompagne généralement d’une hausse de l’utilisation mémoire

    • Sur des runners CI disposant de peu de cœurs CPU et de peu de mémoire, il peut être préférable de réduire la valeur afin d’éviter un surcoût inutile
    • --checkers 1 rend de fait la vérification de types mono-thread et élimine le travail redondant
    • Dans de rares cas, changer le nombre de --checkers peut révéler des résultats dépendants de l’ordre ; il peut donc être utile d’imposer un nombre fixe de checkers dans tout l’environnement de build

  • --builders

    • --builders contrôle le nombre de builders de références de projet pouvant s’exécuter simultanément lors d’un --build
    • Cela peut être particulièrement utile dans les monorepos comportant de nombreux projets
    • Augmenter la valeur peut accélérer la build, mais aussi accroître l’utilisation mémoire
    • Il y a un effet multiplicateur avec --checkers : --checkers 4 --builders 4 peut lancer jusqu’à 16 vérificateurs de types en parallèle
    • Contrairement à --checkers, modifier le nombre de --builders ne devrait pas produire de résultats différents
    • La build avec références de projet est par défaut limitée par le graphe de dépendances des projets

  • --singleThreaded

    • --singleThreaded force l’exécution de l’ensemble du compilateur sur un seul thread
    • Cela peut être utile pour le débogage, la comparaison des performances entre TypeScript 6 et 7, l’orchestration externe de builds parallèles, ou dans des environnements aux ressources très limitées
    • Ce flag ne se contente pas de limiter à 1 le nombre de workers de vérification de types : il force aussi le parsing et l’emit à s’exécuter sur un seul thread

Nouveau mode --watch

  • TypeScript 7 a entièrement reconstruit le mode --watch
  • Le nouveau --watch s’appuie sur le file-watcher du bundler Parcel pour offrir une surveillance de fichiers efficace, stable et multiplateforme
  • La bibliothèque standard de Go ne propose pas d’API intégrée de surveillance de fichiers, et les bibliothèques tierces examinées posaient des problèmes de fiabilité, de performances, de support multiplateforme ou d’intégration avec les outils de build
  • Une approche en pur polling fonctionnait sur plusieurs systèmes d’exploitation, mais son coût de calcul était élevé sur de gros projets avec de nombreuses dépendances node_modules
  • L’équipe TypeScript a porté en Go @parcel/watcher, déjà utilisé dans VS Code, en s’appuyant sur un shim assembleur minimal afin d’éviter les dépendances à une toolchain C++
  • Ce watcher est un package indépendant, et apporte dans le mode --watch de TypeScript 7 une meilleure utilisation des ressources sur l’ensemble des plateformes

Valeurs par défaut de TypeScript 6.0 et changements de compatibilité

  • TypeScript 7.0 a été conçu pour rester compatible avec la vérification de types et le comportement en ligne de commande de TypeScript 6.0
  • Avec le flag stableTypeOrdering activé et sans configuration de ignoreDeprecations, un code qui compile proprement avec TypeScript 6.0 devrait compiler de manière identique avec TypeScript 7.0
  • TypeScript 7.0 adopte les nouvelles valeurs par défaut de TypeScript 6.0 et produit une hard error pour les flags et syntaxes dépréciés dans TypeScript 6.0
  • Les principaux changements de valeurs par défaut sont les suivants
    • strict vaut désormais true par défaut
    • module vaut désormais esnext par défaut
    • target vaut désormais par défaut la version ECMAScript stable actuelle juste avant esnext
    • noUncheckedSideEffectImports vaut désormais true par défaut
    • libReplacement vaut désormais false par défaut
    • stableTypeOrdering vaut désormais true par défaut et ne peut pas être désactivé
    • rootDir vaut désormais ./ par défaut
    • types vaut désormais [] par défaut ; l’ancien comportement peut être rétabli avec ["*"]
  • Les changements concernant rootDir et types sont considérés comme les plus susceptibles de surprendre
    • Les projets dont le tsconfig.json se trouve hors d’un répertoire source comme src doivent préciser rootDir afin de conserver la structure de répertoires existante
    • Les projets dépendant de certaines déclarations globales doivent indiquer dans types les packages @types nécessaires
{
  "compilerOptions": {
    "rootDir": "./src"
  },
  "include": ["./src"]
}

{
  "compilerOptions": {
    "types": ["node", "jest"]
  }
}

Comportements supprimés ou transformés en hard error

  • Dans TypeScript 7.0, plusieurs options et syntaxes dépréciées dans TypeScript 6.0 ne sont plus prises en charge
  • Les principaux éléments sont les suivants
    • target: es5 n’est plus pris en charge
    • downlevelIteration n’est plus pris en charge
    • moduleResolution: node/node10 n’est plus pris en charge ; nodenext et bundler sont recommandés
    • module: amd, umd, systemjs, none n’est plus pris en charge ; esnext ou preserve sont recommandés avec une résolution de modules via bundler ou navigateur
    • baseUrl n’est plus pris en charge ; paths peut être mis à jour avec des chemins relatifs à la racine du projet à la place de baseUrl
    • moduleResolution: classic n’est plus pris en charge ; bundler ou nodenext sont recommandés
    • esModuleInterop et allowSyntheticDefaultImports ne peuvent plus être définis à false
    • alwaysStrict est considéré comme true et ne peut plus être défini à false
    • Le mot-clé module ne peut plus être utilisé dans les déclarations de namespace
    • Le mot-clé asserts ne peut plus être utilisé dans les imports ; il faut utiliser with pour suivre l’évolution de la syntaxe des import attributes d’ECMAScript
    • Sous skipDefaultLibCheck, la directive /// <reference no-default-lib /> n’est plus respectée
    • Si un tsconfig.json est présent dans le répertoire courant, la ligne de commande de build ne peut plus recevoir de chemins de fichiers, et un --ignoreConfig explicite est requis

Types de littéraux de template et changements du support JavaScript

  • TypeScript 7.0 traite plus naturellement les points de code Unicode dans l’inférence des types de littéraux de template
type HeadTail<S> = S extends `${infer Head}${infer Tail}` ? [Head, Tail] : never;

type Result = HeadTail<"😀abc">;
// 7.0: ["😀", "abc"]
// Avant: ["\ud83d", "\ude00abc"]
  • Auparavant, TypeScript suivait le comportement d’indexation UTF-16 de JavaScript et découpait "😀" en deux parties de paire de substitution
  • Le nouveau comportement correspond mieux à l’intuition de for...of ou [...str], qui traitent "😀" comme une seule unité
  • Cela peut constituer un breaking change pour les manipulations de chaînes au niveau des types qui modélisaient volontairement des code units UTF-16
  • Le support JavaScript a aussi été retravaillé pour être plus cohérent avec la manière dont les fichiers TypeScript sont analysés
    • Une valeur ne peut pas être utilisée à la place d’un type ; il faut utiliser typeof someValue
    • @enum ne bénéficie plus d’un traitement spécial
    • Un ? isolé ne peut plus être utilisé comme type ; il faut utiliser any
    • @class ne transforme plus une fonction en constructeur ; il faut utiliser une déclaration class
    • Le ! postfixe n’est plus pris en charge
    • Les noms de types doivent être définis dans des tags @typedef
    • La syntaxe de fonction de style Closure n’est plus prise en charge ; il faut utiliser la syntaxe abrégée de TypeScript
  • Certains patterns JavaScript, comme l’aliasing de this ou la réaffectation complète du prototype d’une fonction, ne bénéficient plus non plus d’un traitement spécial
  • Les différences entre TypeScript 6.0 et 7.0 sont détaillées plus largement dans CHANGES.md

Fonctionnalités de l’éditeur et limites

  • TypeScript 7.0 ajoute plusieurs fonctionnalités d’éditeur qui manquaient depuis la beta
  • Cela inclut l’import automatique, le hover extensible, les inlay hints, le code lens, go-to-source-definition, l’édition liée JSX et la complétion de balises
  • Des fonctionnalités absentes de la beta de TypeScript 7.0, comme la coloration sémantique, « sort imports » et « remove unused imports », sont également de retour
  • Pour améliorer la qualité du serveur de langage, l’infrastructure de test et de diagnostic a été reconstruite, et il est possible d’exécuter des fuzz tests sur les principaux codebases TypeScript et JavaScript de GitHub

Contraintes actuelles des workflows de langage intégrés

  • Les workflows utilisant Vue, MDX, Astro, Svelte, etc. ne pourront probablement pas encore tirer parti de TypeScript 7
  • Les vérifications de types pour des templates spécialisés, comme les templates Angular, ne pourront probablement pas non plus utiliser TypeScript 7
  • La raison principale est que TypeScript 7 n’expose pas encore d’API de programmation stable
  • Les outils qui intègrent TypeScript dans leur propre compilateur et service de langage, comme Volar, n’ont pour l’instant pas d’autre choix que de dépendre de TypeScript 6.0
  • L’équipe TypeScript considère ce problème comme une contrainte ponctuelle et prévoit de collaborer avec les mainteneurs des projets concernés pour assurer la prise en charge de TypeScript 7
  • D’ici là, l’utilisation de TypeScript 7 est recommandée dans les scénarios qui ne nécessitent pas de plugin de serveur de langage
  • Les projets Angular peuvent utiliser le tsc de TypeScript 7 dans la CLI pour une détection rapide des erreurs à l’échelle du projet, tout en conservant TypeScript 6.0 pour la prise en charge dans l’éditeur
  • Vue, MDX, Astro, Svelte, etc. devront continuer à utiliser TypeScript 6.0 pour le moment
  • Dans VS Code, la commande « Disable TypeScript 7 Language Server » permet de revenir à TypeScript 6.0

Feuille de route

  • La sortie de TypeScript 7.0 constitue un jalon majeur du portage natif, sur lequel le projet TypeScript se concentre depuis plus d’un an
  • Après 7.0, l’équipe prévoit de reprendre le travail sur les nouvelles fonctionnalités, les améliorations d’ergonomie, des optimisations de performances supplémentaires et l’implémentation de nouvelles API pour l’écosystème
  • Comme avant TypeScript 7.0, de nouvelles releases de fonctionnalités devraient sortir tous les 3 à 4 mois
  • TypeScript 7.1 doit combler certains écarts pour faciliter la transition de la communauté et fournir de nouvelles API

À lire aussi

2 commentaires

 
GN⁺ 2 시간 전
Avis de Hacker News

  • D’après leurs propres tests, les gains de vitesse de TypeScript 7 sont les suivants

    Codebase TypeScript 6 TypeScript 7 Speedup
    vscode 125.7s 10.6s 11.9x
    sentry 139.8s 15.7s 8.9x
    bluesky 24.3s 2.8s 8.7x
    playwright 12.8s 1.47s 8.7x
    tldraw 11.2s 1.46s 7.7x

    L’équipe est impressionnante d’avoir obtenu de tels résultats tout en menant la migration de manière responsable. Bun devrait en prendre de la graine. Ce que je me demande, c’est quel impact cela aura sur les outils de plus bas niveau qui doivent builder des codebases TypeScript, comme tsdown ou esbuild, et s’il est possible d’utiliser TS 7 avec tsdown aujourd’hui

    • esbuild ne dépend pas du tout de TypeScript, donc pas de problème. Pour tsdown, cela dépend de l’utilisation ou non de --isolatedDeclarations ; sinon, il suffit d’installer TypeScript 6 en parallèle comme l’indique le billet de blog
    • Je me demande si tu considères que la migration de Bun a été irresponsable

  • Il fut un temps où l’on débattait pour savoir si les types valaient vraiment l’effort qu’ils demandaient. Ce qui est formidable avec TypeScript, c’est avant tout qu’il a popularisé les types

    • Je ne me souviens pas vraiment de gens qui détestaient les types. Ce que beaucoup de gens n’aimaient pas, c’était le typage statique, plus précisément le typage statique et explicite
      Par exemple, j’ai entendu plusieurs fois des gens dire qu’ils ne pouvaient pas utiliser Python parce qu’il n’avait pas de types, ce qui n’a aucun sens. Python est un langage fortement typé, il est simplement typé dynamiquement.
      Il existe bien des langages sans véritables types, ou généralement « stringly typed ». AREXX, que j’ai manipulé quand j’étais jeune, stockait toutes les valeurs sous forme de chaînes, même celles qui ressemblaient à des nombres, et on peut voir la plupart des outils CLI Unix comme sed de la même manière. Mais la plupart des débats autour des types concernaient des langages à typage dynamique comme Python, et je n’ai presque jamais vu quelqu’un dire que les langages faiblement typés ou sans types étaient adaptés aux grands projets. Au contraire, j’ai souvent entendu des gens qualifier à tort Python de langage « sans types » et dire qu’il ne pouvait pas être utilisé pour de grands projets, ce qui était déroutant pour quelqu’un qui travaillait justement sur de grands projets en Python
    • Les anciens systèmes de types n’étaient tout simplement pas terribles. Être forcé d’utiliser des hiérarchies de classes pour exprimer des types « OR », comme les types somme, est pénible. Les langages modernes dotés de types somme, comme TypeScript, Rust, Swift ou Kotlin, sont bien plus agréables
    • Personnellement, j’ai eu trois discussions avec des gens qui disaient presque mot pour mot : « je n’ai jamais eu d’erreur de typage en JavaScript ». Deux d’entre eux étaient des personnes dont je respectais le travail, donc j’avais du mal à comprendre comment elles pouvaient défendre une telle position
    • Je pense que les types de données algébriques et le pattern matching ont changé la donne. Même sans aller aussi loin que Haskell, les types sont soudain devenus beaucoup plus utiles
      À l’époque, l’exposition aux types passait surtout par C++/Java, et C++ en particulier peut difficilement servir de bon exemple pour autre chose que la manière de créer un langage excessivement complexe. Il devient beaucoup plus facile de convaincre quelqu’un une fois qu’il a vu des types bien utilisés
    • Il ne reste plus qu’à attendre DependentTypeScript

  • Ce qui est vraiment impressionnant ici, c’est cette excellente équipe qui maintient simultanément deux codebases distinctes pour le système de types le plus avancé connu de l’humanité. J’ai hâte de voir la réécriture en Rust

    • Je ne suis pas sûr qu’une réécriture en Rust ait beaucoup de sens. Go permet de coder vite, et il est facile de réimplémenter TypeScript en 1:1 en suivant le code
      Rust prendrait beaucoup plus de temps à développer. Même si Rust pouvait être 20 % plus rapide que Go, le gain obtenu en passant de TypeScript à Go est déjà énorme. Sur vscode, Rust donnerait peut-être 14x au lieu des 11x de Go, mais Go suffit déjà largement à faire une grande différence
    • C’est peut-être le plus complexe, mais je ne sais pas si c’est le système de types « le plus avancé ». Il n’y a probablement pas de bonne réponse à ce titre, mais l’un des langages d’assistant de preuve me semblerait être un candidat plus plausible
      Je ne veux pas dénigrer le système de types de TypeScript ; c’est réellement un travail très intéressant
    • Steve Francia, qui a créé Hugo et plusieurs grands projets Go, a écrit un article sur Go à l’ère des agents : https://spf13.com/p/go-the-agentic-language/
    • Je me demande ce que signifie exactement « le système de types le plus avancé connu de l’humanité »
    • D’après ce que j’ai compris, ils ont sérieusement évalué Rust et d’autres options avant de choisir Go. Je ne me souviens pas de toutes les raisons, mais elles étaient détaillées dans le billet de blog d’origine

  • Après quelques années avec TypeScript, le fait de devoir ajouter soi-même des annotations de type en Python et d’importer des fonctionnalités de base du langage comme abc me semble vraiment fastidieux

  • C’est intéressant, mais maintenant que Node supprime nativement les annotations de type TypeScript, je n’exécute presque plus TSC. Je ne le lance que lorsque j’ai créé une grosse régression et que j’ai besoin de vérifier, via la sortie statique du compilateur, ce que je n’ai pas réussi à mettre à jour
    Même pour le code frontend destiné au navigateur, je m’appuie sur la suppression des types par Node

    • C’est vrai, mais d’un autre côté, l’éditeur fait tourner le serveur de langage TypeScript toute la journée. C’est probablement aussi le cas de la CI, et les agents IA le feront sans doute avant d’être sûrs du travail qu’ils viennent d’effectuer

  • Je suis content que la syntaxe de types JSDoc continue de recevoir de l’attention. C’est ma façon préférée d’utiliser TypeScript dans mes projets personnels. Certaines modifications de syntaxe seront pénibles à mettre à jour, mais la plupart semblent aller dans le bon sens

  • L’une des grandes douleurs de TypeScript, c’est qu’il est difficile d’ajuster la portée des réglages tsconfig, comme lib et types, pour une partie d’un projet
    Le projet est une appli web, mais à cause de vite.config.ts, Playwright et des tests unitaires, les types Node se retrouvent côté outillage dans l’IDE. Même si l’on ajoute une API Node à un composant React, tsc ne se plaint pas.
    Actuellement, pour isoler les bibliothèques DOM et Node, il faut un spaghetti de références de projets, de nombreux fichiers tsconfig.json et des fichiers de sortie tsbuildinfo, et il est aussi fastidieux d’éviter la sortie des types tout en utilisant les références de projets

    • Je suis d’accord, c’est vraiment la partie pénible. J’utilise nx, qui gère ce genre de choses à ma place. Playwright est un projet séparé avec son propre tsconfig, et tous héritent du tsconfig racine
      Même pour une application unique, je préfère nx, et je déplace le code partagé dans des « bibliothèques ». J’utilise des bibliothèques qui ne sont pas buildées, et sur de gros projets c’est plutôt appréciable

  • Il n’y a pas encore d’API du compilateur TypeScript, mais comme elle serait en cours de développement, je suis impatient

    • Elle devrait arriver en 7.1

  • Quand on voit les graphiques montrant une baisse de l’utilisation mémoire et une forte hausse des performances, on se dit qu’il faudrait peut-être utiliser Go côté serveur plutôt que TypeScript

    • D’abord, on n’exécute pas TypeScript côté serveur. Quel que soit le moteur d’exécution utilisé, on exécute du code transformé ou du JavaScript
      Et je ne comprends pas vraiment pourquoi, avec les options disponibles aujourd’hui, certains lancent encore de nouveaux projets en TS/JS/Python
    • C’est peut-être parce qu’ils peuvent partager des types ou des modules avec le projet frontend. Ou parce que, pour des applications peu gourmandes en CPU, la différence est quasi inexistante ; ou encore parce qu’ils connaissent et aiment cet écosystème. Il y a aussi le fait que l’écosystème de bibliothèques est immense
    • Il s’agit ici des performances de build, pas des performances à l’exécution
    • L’importance de l’écart de performance entre Go et JS (Node, etc.) dépend du cas d’usage. Pour le compilateur TypeScript, c’est clairement important, mais pour une appli CRUD, ça peut ne pas l’être du tout
    • Parce que, quand c’est possible, il est plus simple de travailler avec un seul langage principal

  • Félicitations à l’équipe TypeScript. J’aurais de quoi en faire un long billet ou un enregistrement audio, mais pour le dire brièvement, l’écosystème JavaScript/TypeScript ressemble au fait de travailler le bois
    On peut fabriquer des choses façon Ikea, avec du bois aggloméré stratifié bon marché. En code, ce serait une appli de vibe coding sans originalité.
    À l’inverse, on peut aussi produire des meubles artisanaux haut de gamme ou des immeubles de grande hauteur en bois. En utilisant du bois jeune, avec des assemblages sur mesure et des techniques de lamination pour créer des poutres résistantes au feu. Dans l’écosystème JavaScript/TypeScript aussi, on peut utiliser l’IA comme une machine-outil puissante tout en gardant un esprit d’artisan, et obtenir des résultats de grande qualité. Si vous avez le courage de créer quelque chose et de le lancer, il suffit d’adopter l’écosystème TypeScript/JavaScript
 
GN⁺ 2 시간 전
Avis sur Lobste.rs

  • Je comprends la raison, mais il est intéressant de voir le passage d’un compilateur auto-hébergé à un compilateur qui ne l’est pas.
    C’est un mouvement rare, car en général on va presque toujours dans le sens inverse.

    • Je pense qu’on devrait voir cette direction plus souvent. Tous les langages ne se prêtent pas à l’écriture de compilateurs.
      L’auto-hébergement exerce une forte pression pour faire évoluer le langage vers un langage plus adapté à l’écriture du compilateur, et ce n’est pas toujours forcément la bonne direction.
    • C’est surprenant de voir des concepteurs et implémenteurs de langage comprendre que leur propre langage n’est pas parfait pour tous les usages.

  • Même si l’on ne code pas en TypeScript, VSCode lui-même étant écrit en TypeScript, je me demande si cette amélioration a aussi un impact sur la vitesse de VSCode.
    Ou si elle ne concerne que l’extension de langage TypeScript.

    • C’est le compilateur qui devient plus rapide, il ne produit pas comme par magie du code plus rapide.
    • Cela ne concerne que l’extension de langage TypeScript.
    • TypeScript est compilé en JavaScript. Quand VSCode s’exécute, node.js et Chromium exécutent du code JavaScript.
      Ce qui devient plus rapide ici, c’est uniquement le compilateur qui prend le code TypeScript et le transforme en JavaScript, et ce processus a lieu dans la chaîne de build avant que Microsoft ne distribue l’exécutable de VSCode.
      La seule exception possible serait que le serveur LSP TypeScript puisse lui aussi devenir plus rapide, car il parse effectivement du code TypeScript à l’exécution. Mais cela reste indépendant du fait que VSCode soit écrit en TypeScript.
    • Le compilateur TypeScript ne fait en réalité pas grand-chose. tsc a pour principe de ne pas toucher au code qu’il traite, sauf pour le strict minimum comme la suppression des types, ce qui fait que pas mal de choses sont marquées WONTFIX.
      Je m’attends donc à ce que les caractéristiques de performance des outils créés avec TypeScript changent très peu.

  • Petite astuce personnelle. Le projet sur lequel je travaille actuellement utilise TS 5, mais comme prévu je ne voulais pas l’utiliser dans nvim.
    J’ai donc d’abord installé TS 7 avec mise, puis créé dans node_modules/.bin un lien symbolique tsgo pointant vers le TS installé avec mise.
    Comme nvim-lspconfig utilise encore l’ancien nom de fichier tsgo de l’époque de la préversion technique, nvim exécute le TS 7 installé au lieu du TS local.