Journal

Progression

• TypeScript 7.0.2 épinglé dans le package.json et le fichier de verrouillage propres au cours, avec @types/node 24.13.4 et tsx 4.23.13
• CI : tsc sur le projet et sur chaque extrait d’erreur, chaque exemple et chaque solution exécutés avec Node.js 24.21.0, les comparaisons C# et Java compilées et exécutées, le tout comparé à la sortie attendue sur trois OS
• Leçon 1 : le compilateur et l’outillage
• Leçon 2 : le typage structurel
• Leçon 3 : unions et narrowing
• Leçon 4 : génériques
• Leçon 5 : programmation au niveau des types

QA

Le compilateur TypeScript en 7.0.2 — le portage en Go — avec Node.js 24 et npm 11. La moitié de ces lignes sont des changements délibérés qui cassent une habitude plutôt que des défauts, et la colonne État dit lesquels. La quatrième ligne est le seul endroit où l’auteur attendait une erreur, ne l’a pas eue, et où c’est le compilateur qui avait raison.

Il n’y a pas de tableau d’expériences : cette quatrième ligne est la seule prédiction du journal écrite avant son épreuve, et un tableau d’une ligne se lirait comme une section qu’on n’a pas su remplir.

Attendu	Ce qui se passe	Où	Mesure	État
tsc --noEmit avec des erreurs rend le code de sortie qu’il a toujours rendu	Le code a changé entre la 6.0 et la 7.0	tsc 6.0.3 contre 7.0.2	La 6.0.3 rend 2, la 7.0.2 rend 1. En 7.0.2, 1 signifie que les erreurs ont empêché la sortie et 2 qu’elle a été écrite malgré elles	Par conception, rupture assumée. Une étape de CI qui teste 2 casse à la montée de version ; tester le non-nul 2026-09-15
tsc file.ts à côté d’un tsconfig.json ignore la configuration en silence	Depuis la 6.0, c’est une erreur	tsc 6.0 et suivantes	TS5112. --ignoreConfig rétablit l’ancien comportement ; le cours construit plutôt un petit tsconfig par extrait fautif	Par conception 2026-09-15
Les membres d’une union s’affichent dans l’ordre de déclaration	Non, et l’ordre a changé entre versions	tsc 5.9.3 contre 7.0.2	Sur le ForceRadiant.tsx de GA : `“warning”	“error”
Une annotation de variance out fausse est refusée	interface Mislabeled<out T> { accept(value: T): void } compile	tsc 7.0.2	Les paramètres de méthode sont bivariants : T à cette place satisfait donc les deux annotations. C# signale la même interface en CS1961. L’extrait a été remplacé par in T sur une méthode qui rend T, que tsc attrape bien en TS2636	Par conception. L’auteur attendait une erreur et c’est le compilateur qui avait raison — c’est la leçon qui a changé, pas lui 2026-09-15
Array.isArray affine un unknown sans danger	Il l’affine en any[] : un accès de propriété compile donc sans le moindre contrôle	tsc 7.0.2, la déclaration de Array.isArray dans la lib	Dans la solution de l’exercice 2 de la leçon 2, item.name compilait sans contrôle, et tsc n’a jamais réclamé les typeof qui rendent le code correct	Par conception, et bon à savoir 2026-09-15
Une API stable est silencieuse	module.stripTypeScriptTypes affiche encore un ExperimentalWarning, alors que le retrait de types lui-même est stable et muet	Node.js 24.21.0	L’avertissement, à chaque appel	Reproduit, non signalé — le meilleur candidat amont de ce journal 2026-09-15
L’erreur de Node montre la ligne telle qu’elle est écrite	La ligne de source du message porte des espaces là où étaient les types	retrait de types de Node.js 24.21.0	const guitarSource = instrumentSource; — c’est ainsi que le retrait préserve les numéros de ligne et de colonne	Par conception 2026-09-15
dotnet run file.cs affiche les avertissements du compilateur à chaque exécution	Il construit de façon incrémentale : une seconde exécution sur une source inchangée les affiche une fois et plus jamais	programmes .NET 10 en fichier unique	Le premier passage en CI a échoué sur les trois OS pour deux fichiers : CS8602 et CS8509 étaient dans la sortie de la CI et pas dans celle de l’auteur. Corrigé par dotnet clean puis dotnet run --no-cache	Reproduit en CI et en local, non signalé 2026-09-14
Un compilateur plus récent signale les mêmes erreurs	TypeScript 7 en trouve davantage, et bien plus vite	tsc 5.9.3 contre 7.0.2 sur ga-react-components	180 erreurs en 14,7 s avec la 5.9.3 ; 197 en 1,9 s avec la 7.0.2. Codes nouveaux : TS2591, parce que types vaut désormais [] par défaut ; TS2871 « this expression is always nullish » ; TS2550 pour .at() avec lib à ES2020	Reproduit. Le journal consigne sa propre réserve : les versions des dépendances viennent d’une installation non gelée 2026-09-15
npm exécute les scripts d’installation	npm 11.19 ne les exécute plus par défaut	npm 11.19 avec tsx 4.23.13	npm warn install-scripts esbuild@0.28.2 (postinstall: node install.js). tsx marche quand même sur les trois OS, le binaire d’esbuild arrivant en paquet de plateforme optionnel	Par conception, défaut modifié 2026-09-14
TypeScript 7.0 offre une API programmatique	Il n’en a pas encore ; les outils qui chargent le compilateur en bibliothèque passent par @typescript/typescript6, un paquet de compatibilité qui fournit la 6.0 avec une commande tsc6	TypeScript 7.0	Lu dans la documentation, pas exercé — le cours n’en a pas eu besoin	Par conception, un manque connu du portage en Go 2026-09-14
Un fichier de verrouillage écrit sous Windows doit être refait sous Linux	Il liste les vingt paquets de plateforme en dépendances optionnelles : un seul fichier sert aux trois systèmes	typescript 7.0.2, le portage en Go	@typescript/typescript-win32-x64 en local ; l’étape de CI liste typescript-linux-x64 et typescript-darwin-arm64	Par conception, et c’est ce qui rend la CI à trois OS peu coûteuse 2026-09-14

2026-09-14 — Installer TypeScript 7.0.2

• npm view typescript version donne 7.0.2, le portage en Go, publié le 2026-07-08. Le package typescript est maintenant petit : npm installe le compilateur sous forme d’un package par plateforme, @typescript/typescript-win32-x64 sur ma machine, et l’étape d’information de la CI liste typescript-linux-x64 sous Linux et typescript-darwin-arm64 sous macOS. Le fichier de verrouillage liste les vingt packages de plateforme comme dépendances optionnelles, donc npm ci fonctionne sur les trois OS à partir de l’unique fichier de verrouillage écrit sous Windows.
• TypeScript 7.0 n’a pas encore d’API programmatique. Les outils qui chargent le compilateur comme bibliothèque peuvent utiliser @typescript/typescript6, un package de compatibilité qui fournit TypeScript 6.0 avec une commande tsc6 ; je n’en ai pas eu besoin pour le cours.
• Le cours épingle ses versions dans code/typescript-for-csharp-java/package.json, pas dans celui du site : le site lui-même n’a pas de dépendance typescript.
• npm 11.19 n’exécute plus les scripts d’installation par défaut. L’installation de tsx a affiché npm warn install-scripts esbuild@0.28.2 (postinstall: node install.js), et tsx fonctionne quand même, sur les trois OS : le binaire d’esbuild vient d’un package de plateforme installé comme dépendance optionnelle.

2026-09-14 — La CI

• typescript-examples.yml installe Node.js 24.21.0, .NET 10 et Java 25, exécute npm ci dans le dossier du cours, puis check.sh avec REQUIRE_COMPARE=1, pour qu’un dotnet ou un java manquant fasse échouer l’exécution au lieu de sauter les comparaisons.
• check.sh exécute tsc une fois sur tout le projet, qui doit passer, et une fois par extrait d’erreur, avec un tsconfig généré qui étend celui du cours et liste ce seul fichier ; un extrait peut demander des options supplémentaires avec un commentaire // tsc options:, comme le fait celui de la leçon 2 pour noUncheckedIndexedAccess. normalize.mjs, adapté du cours JavaScript, rend les chemins relatifs et retire les frames de la pile et les identifiants de processus.
• La première exécution a échoué sur les trois OS, sur deux fichiers seulement, et pour la même raison : les avertissements C# CS8602 et CS8509 figuraient dans la sortie de la CI et pas dans la mienne. dotnet run file.cs compile un programme basé sur un fichier de façon incrémentale, et une seconde exécution avec une source inchangée n’appelle pas le compilateur, donc ses avertissements ne s’affichent qu’une fois. check.sh exécute maintenant dotnet clean sur le fichier avant dotnet run --no-cache, et les sorties capturées sous Windows correspondent sous Linux et macOS. L’exécution suivante est passée sur les trois OS en 2 minutes 41 secondes, Windows étant le job le plus lent.

2026-09-15 — Surprises en écrivant les leçons 1-4

Le code de sortie de tsc a changé entre 6.0 et 7.0. Avec --noEmit et des erreurs, tsc 6.0.3 renvoie 2, et 7.0.2 renvoie 1. Dans 7.0.2, 1 signifie que des erreurs ont empêché la sortie, avec noEmit ou noEmitOnError, et 2 que la sortie a été écrite malgré des erreurs, ce que la leçon 1 montre avec l01-emit. Une étape de CI qui teste $? -eq 2 casserait à la mise à jour ; teste un code non nul.

tsc file.ts à côté d’un tsconfig.json est une erreur depuis 6.0. TS5112 refuse d’ignorer la configuration en silence, comme le faisaient les anciennes versions ; --ignoreConfig rétablit l’ancien comportement. check.sh construit plutôt un petit tsconfig pour chaque extrait d’erreur.

Les membres d’une union ne s’affichent pas dans l’ordre de déclaration. La même comparaison dans le ForceRadiant.tsx de GA affiche "warning" | "error" | "unknown" | "contradictory" avec 5.9.3 et "contradictory" | "error" | "unknown" | "warning" avec 7.0.2. Les notes de version de la 6.0 l’expliquent : TypeScript 7 trie les types selon leur contenu pour que des vérificateurs parallèles tombent d’accord. Les sorties attendues de la leçon 3 sont uniquement celles de 7.0.2.

Une annotation out fausse compile. J’ai écrit interface Mislabeled<out T> { accept(value: T): void } pour l’extrait d’erreur de la leçon 4, en m’attendant à une erreur, et tsc 7.0.2 l’a acceptée : accept est une méthode, les paramètres de méthode sont bivariants, et T à cette position satisfait les deux annotations. C# signale la même interface avec CS1961. L’extrait utilise maintenant l’erreur que tsc détecte, in T sur une méthode qui renvoie T (TS2636).

Array.isArray ramène any. Dans la solution du deuxième exercice de la leçon 2, la valeur était unknown, et Array.isArray(value) l’a restreinte à any[] : item.name compilait sans vérification. Les vérifications typeof de la solution la rendent correcte ; tsc ne les a pas demandées. La leçon 2 le signale.

Node.js affiche la ligne dépouillée de ses types. Quand un fichier .ts échoue à l’exécution, la ligne source dans le message de Node.js contient des espaces là où se trouvaient les types, comme le const guitarSource = instrumentSource; de la leçon 4. C’est ainsi que la suppression des types (type stripping) conserve les numéros de ligne et de colonne.

module.stripTypeScriptTypes affiche encore un ExperimentalWarning en 24.21.0, bien que la suppression des types elle-même soit stable et silencieuse ; la leçon 1 montre l’avertissement.

2026-09-15 — Ce que tsc a trouvé dans GuitarAlchemist/ga (a826864)

J’ai cloné GuitarAlchemist/ga au commit a826864 dans un dossier de travail, installé les deux front ends, et exécuté tsc avec 5.9.3, la version que résout le pnpm-lock.yaml de la bibliothèque de composants, et avec 7.0.2.

• Des noms utilisés et jamais définis. Apps/ga-client/src/components/Chat/ChatInterface.tsx utilise VIRTUALIZATION_THRESHOLD (lignes 69 et 219) et VirtualizedMessageList (lignes 254 et 255), et rien ne les définit ni ne les importe : TS2304. La route /ai-copilot d’App.tsx charge ce composant, donc la page devrait lever une ReferenceError à son rendu (à vérifier dans un navigateur). Reproduction : cd Apps/ga-client && npm ci && npx tsc -b --pretty false | grep ChatInterface. Cela ressemble à un bug qui mérite une issue.
• Les erreurs de type ne font pas échouer le build. Les deux front ends se construisent avec vite build, qui retire les types sans les vérifier ; ga-client signale 346 erreurs avec tsc -b (dont 165 TS6133, des variables inutilisées), et ga-react-components 186. Une étape tsc --noEmit en CI aurait détecté les noms manquants.
• Un fichier de verrouillage périmé. Dans ReactComponents/ga-react-components, pnpm install --frozen-lockfile échoue avec ERR_PNPM_OUTDATED_LOCKFILE : 21 dépendances de package.json manquent dans pnpm-lock.yaml, et les versions de @react-three/drei et @react-three/fiber diffèrent. J’ai installé sans --frozen-lockfile, donc les nombres d’erreurs de la bibliothèque de composants peuvent dépendre des versions que j’ai obtenues.
• Des statuts que le type exclut. ForceRadiant.tsx, lignes 721 et 725 compare un GovernanceHealthStatus à 'ok' et 'critical', que l’union ne contient pas (TS2367), et DataLoader.ts, lignes 276-278 fait passer le healthStatus: string d’un message SignalR par as unknown as GovernanceNode. Soit il manque deux statuts à l’union, soit les comparaisons sont du code mort (à vérifier dans le hub de GA). La ligne 1464 du même fichier compare une sévérité de signal, 'info' | 'warning' | 'emergency', à 'critical'. La leçon 3 reproduit le premier cas sous une forme réduite.
• noImplicitAny: false à côté de strict: true dans ga-react-components/tsconfig.app.json. Le réactiver n’ajoute que quatre erreurs, dans BSPDoomExplorer.tsx et IxqlFormPanel.tsx ; la leçon 2 les liste.
• Des données non vérifiées. La bibliothèque de composants compte 34 as unknown as, 42 appels à JSON.parse et 18 as any. La caméra est restaurée depuis localStorage avec JSON.parse(saved) as { px: number; … } (ForceRadiant.tsx, ligne 3558), loadQueue<T> renvoie JSON.parse comme un T[] (CourseViewer.tsx, ligne 152), et l’isApiResponse<T> de ga-client vérifie deux noms de propriétés avant de promettre un ApiResponse<T>, avec json as T comme repli (musicService.ts, lignes 17-49). Les leçons 3 et 4 et leurs exercices écrivent les versions vérifiées.
• TypeScript 7 en trouve davantage. tsc -p tsconfig.app.json sur la bibliothèque de composants donne 180 erreurs en 14,7 secondes avec 5.9.3 et 197 en 1,9 seconde avec 7.0.2. Les nouvelles erreurs sont des noms Node.js dans deux scripts (TS2591, parce que types vaut maintenant [] par défaut), TS2871 (« this expression is always nullish ») dans BrainstormPanel.tsx ligne 40 et GitHubPollingManager.ts ligne 48, et TS2550 pour .at() dans ChatWidget.tsx ligne 1254, avec lib réglé sur ES2020 ; 5.9.3 ne signalait aucun de ces codes.
• Des détails. ga-client/tsconfig.json a "sourceMaps": true à son niveau supérieur, où tsc l’ignore ; l’option est sourceMap, dans compilerOptions. src/components/PrimeRadiant/index.ts dans la bibliothèque de composants exporte RemediationAction deux fois (TS2300, lignes 101 et 129), et ThreeFretboard.tsx ligne 780 utilise un type GuitarModelStyle qui n’existe pas. Le ShowcasePanel.test.tsx de ga-client utilise le global de Node.js, que les types du projet navigateur ne déclarent pas.

2026-09-15 — Ce que tsc a trouvé dans ce site (8ba378e)

npx -p typescript@7.0.2 tsc --noEmit au commit 8ba378e, avec le tsconfig.json du site, signale trois erreurs, les mêmes qu’avec 6.0.3. Aucune ne casse le site.

• astro.config.mjs, ligne 146 : la barre latérale importée de src/streeling-sidebar.json ne correspond pas au SidebarItemUserConfig de Starlight, parce que l’union inférée de ses entrées ajoute fr?: undefined à l’entrée qui n’a qu’une traduction espagnole. La leçon 3 explique l’inférence.
• code/javascript-for-csharp-java/errors/l04_private_outside.js : le tsconfig.json du site inclut **/*, donc tsc vérifie le code des cours, y compris un extrait d’erreur faux exprès. Les errors/*.ts du cours TypeScript seront pris en compte de la même façon ; exclure code/ dans le tsconfig.json du site limiterait les éditeurs et tsc aux fichiers propres du site.
• src/content.config.ts : astro:content n’est déclaré qu’après astro sync.

À vérifier

• La ReferenceError sur la page /ai-copilot de GA, dans un navigateur.
• Si le hub de gouvernance de GA envoie ok et critical comme statuts de santé.
• Ce que fait le ForceRadiant de GA d’une caméra sauvegardée à laquelle il manque une coordonnée.
• new[] { 1, "two", null } en C#, cité dans la leçon 2 comme refusé faute de meilleur type commun.
• Les commandes d’installation de la leçon 1 sous Linux et macOS en dehors de la CI.