3 Systèmes de types qui ne sont pas TypeScript

TypeScript est la méthode par défaut pour typer JavaScript, mais ce n’est pas la seule. Si vous avez déjà ajouté une étape de compilation à un petit projet juste pour obtenir quelques annotations de types, ou regardé tsc parcourir laborieusement une grande base de code, vous vous êtes probablement demandé s’il existait une approche plus légère pour obtenir la sûreté des types. Il en existe une, et même plusieurs.

Les trois systèmes de types non-TypeScript les plus crédibles pour JavaScript en 2026 sont JSDoc avec // @ts-check, ReScript et Flow : l’un vous offre la vérification de types sans étape de compilation, l’autre vous garantit une robustesse supérieure à TypeScript, et le dernier est un vérificateur historique que vous n’adopteriez que pour maintenir du code existant. Tout ce qui est communément listé dans les comparatifs d’« alternatives à TypeScript » (Deno, Dart, Kotlin/JS) est un runtime ou un langage multiplateforme, et non un système de types superposé à JavaScript.

Il s’agit ici d’une étude comparative destinée aux développeurs qui connaissent déjà TypeScript et souhaitent que les compromis soient clairement énoncés : langage vs. vérificateur, avec ou sans étape de compilation, robustesse face au modèle délibérément non sûr de TypeScript, et état actuel de l’écosystème.

Les trois véritables alternatives à TypeScript en 2026

Un véritable « système de types pour JavaScript » vérifie soit les types dans le code source JavaScript (un vérificateur ou une couche d’annotations), soit compile un langage typé vers JavaScript. Cette définition inclut JSDoc avec @ts-check, ReScript et Flow. Elle exclut Deno (un runtime qui exécute TypeScript par ailleurs), ainsi que Dart et Kotlin/JS (des langages distincts qui ciblent JavaScript comme l’un de leurs backends parmi d’autres). Ces outils méritent d’être connus, mais ils répondent à une question différente.

Pour situer le contexte de référence : à mi-2026, TypeScript 7.0 est la version stable actuelle. Elle a été publiée le 8 juillet 2026 sous la forme d’un portage natif du compilateur en Go, que Microsoft annonce généralement 8 à 12 fois plus rapide que TypeScript 6.0 sur les compilations complètes. TypeScript 6.0 était la dernière version construite sur l’ancienne base de code JavaScript, dont le comportement de vérification de types est préservé dans la version 7.0. Un manque subsiste toutefois : la version 7.0 ne propose pas encore d’API programmatique stable, si bien que la vérification de types dans les templates Vue, Svelte et Angular attend TypeScript 7.1, attendu aux alentours d’octobre 2026. Gardez cela à l’esprit : cela a des implications pour JSDoc, comme nous le verrons plus bas.

JSDoc + @ts-check : le système de types de TypeScript sans l’étape de compilation

Nature : Le typage basé sur JSDoc vous permet d’annoter des fichiers .js ordinaires avec des commentaires structurés et de vérifier les types en utilisant exactement le même moteur que TypeScript : le service de langage TypeScript. Cela est distinct de JSDoc en tant que générateur de documentation ; ici, les annotations pilotent la vérification de types. Le manuel TypeScript documente --checkJs comme l’option qui signale les erreurs dans les fichiers .js, disponible depuis TypeScript 2.3.

Comment l’adopter : Ajoutez un simple commentaire en haut d’un fichier, ou activez deux options tsconfig pour l’ensemble du projet. La documentation JavaScript de VS Code décrit // @ts-check comme le moyen de vérifier quelques fichiers sans l’activer partout.

// @ts-check

/**
 * @typedef {{ id: number, name: string }} User
 */

/**
 * @param {User} user
 * @returns {string}
 */
function greet(user) {
  return `Hi, ${user.name}`;
}

Pour un projet entier, omettez le commentaire par fichier :

{
  "compilerOptions": {
    "allowJs": true,
    "checkJs": true
  }
}

Les types JSDoc étant de simples commentaires effaçables, le fichier s’exécute comme du JavaScript standard dans n’importe quel navigateur ou runtime sans étape de compilation — c’est également pourquoi vous pouvez les adopter fichier par fichier. Le compromis : vous héritez du modèle TypeScript à l’identique, y compris son caractère délibérément non sûr, et la syntaxe d’annotation est plus verbeuse qu’en .ts. Une note importante pour l’ère de la version 7.0 : Microsoft a réécrit de zéro la vérification de types JavaScript pour TypeScript 7.0 et a supprimé quelques balises peu utilisées — TypeScript 7.0 ne reconnaît plus les balises @enum et @constructor.

Quand le choisir : Vous souhaitez une sûreté de types incrémentale sur une base de code JavaScript existante, ou pour une bibliothèque distribuée en JS pur, sans étape de compilation.

ReScript : types sûrs, nominaux et entièrement inférés

Nature : ReScript est un langage distinct qui compile vers JavaScript — et non une couche d’annotations —, doté d’un système de types hérité d’OCaml. Le système de types de TypeScript est délibérément non sûr : il accepte certains programmes incorrects afin de rester compatible avec la sémantique d’exécution de JavaScript. C’est précisément ce manque que ReScript comble : il est entièrement inféré et, comme le formule le projet, ne comporte ni any, ni types magiques, ni undefined surprise. Contrairement au typage structurel de TypeScript, où tout objet ayant la bonne forme satisfait un type, les enregistrements et les variantes de ReScript sont nominaux : deux types structurellement identiques ne sont pas interchangeables à moins d’une déclaration explicite en ce sens.

Comment l’adopter : Installez le compilateur et configurez rescript.json, le fichier de compilation unique et obligatoire pour tout projet ReScript (il s’appelait bsconfig.json dans les versions antérieures à ReScript 11). ReScript 12, publié le 25 novembre 2025, supprime entièrement le support de bsconfig.json et utilise les modules ES par défaut.

{
  "name": "my-app",
  "sources": { "dir": "src", "subdirs": true },
  "package-specs": { "module": "esmodule", "in-source": true },
  "suffix": ".res.js"
}

Vous pouvez choisir librement le suffixe des fichiers JS générés ; l’équipe recommande .res.js ou .res.mjs, ce qui correspond également aux modèles officiels create-rescript-app. Un module minimal :

let add = (a: int, b: int): int => a + b
let result = add(1, 2)
Console.log(result)

Le coût est réel : c’est un langage différent avec sa propre syntaxe, vous devez écrire des bindings d’interopérabilité pour utiliser des bibliothèques JavaScript, et l’écosystème est bien plus restreint que celui de TypeScript. Cependant, ReScript a été conçu avec une adoption progressive en tête : si vous souhaitez un jour revenir au JavaScript pur, il vous suffit de supprimer les fichiers sources et de conserver le code JavaScript propre généré.

Quand le choisir : Un projet démarrant de zéro où vous souhaitez les garanties de types les plus solides possibles et êtes prêt à vous engager dans un langage, et non de simples annotations.

Flow : toujours présent, largement dépassé

Nature : Flow est un vérificateur de types statique open-source pour JavaScript, développé par Facebook/Meta et écrit en OCaml. Comme Flow, ReScript descend d’OCaml, mais les deux se trouvent aujourd’hui aux antipodes en termes d’adoption. Flow est un vérificateur, non un langage : vous annotez des fichiers .js, les marquez avec // @flow, et supprimez les types avec Babel lors de la compilation.

// @flow
function add(a: number, b: number): number {
  return a + b;
}

Réalité de l’adoption en 2026 : Flow reste utilisé en production chez Meta sur des millions de fichiers JavaScript et React, mais son écosystème externe s’est considérablement réduit : moins de définitions de bibliothèques, moins de tutoriels et un outillage bien moins fourni que TypeScript. La migration des principaux projets liés à Meta de Flow vers TypeScript a été évoquée dans les discussions communautaires, mais aucune source primaire ne confirme de calendrier précis. Considérez les comparatifs plus anciens qui prédisaient « un bel avenir pour Flow » comme obsolètes ; la dynamique s’est déplacée vers TypeScript il y a plusieurs années.

Quand le choisir : En pratique, uniquement lorsque vous maintenez une base de code Flow existante. Pour tout nouveau projet, les deux autres options constituent des choix bien plus solides.

Verdict : adaptez l’outil à la situation

Optez pour JSDoc avec @ts-check lorsque vous souhaitez un typage incrémental sans aucun outillage de compilation et une compatibilité totale avec le JavaScript pur. C’est la réponse la plus sous-utilisée et la plus pragmatique, puisqu’il s’agit du propre vérificateur de TypeScript appliqué aux fichiers .js. Choisissez ReScript lorsque vous démarrez un projet de zéro et souhaitez une robustesse de types maximale, en acceptant un langage distinct et des bindings d’interopérabilité comme contrepartie. Conservez Flow uniquement pour maintenir du code déjà écrit avec ce vérificateur. Si vous souhaitez la sûreté des types sans quitter JavaScript dès aujourd’hui, ajoutez // @ts-check à un seul fichier et observez les erreurs apparaître.

Questions fréquentes

Peut-on utiliser la vérification de types JSDoc sans installer TypeScript comme dépendance ?

Les éditeurs comme VS Code embarquent le service de langage TypeScript nativement, de sorte qu'ajouter // @ts-check à un fichier .js vous offre la vérification de types sans aucun npm install. Pour effectuer la même vérification en ligne de commande ou en intégration continue, vous installez le package typescript et exécutez tsc avec les options allowJs et checkJs activées. Les types eux-mêmes restant dans des commentaires JSDoc, rien n'est ajouté à votre JavaScript distribué dans les deux cas.

Quelle est la différence entre le typage structurel de TypeScript et le typage nominal de ReScript ?

Le typage structurel, utilisé par TypeScript, considère que tout objet ayant la bonne forme satisfait un type : deux types sans relation mais avec des champs identiques sont donc interchangeables. Les enregistrements et variantes de ReScript sont nominaux, ce qui signifie que deux types structurellement identiques sont traités comme distincts à moins que vous ne déclariez explicitement une relation entre eux. Le typage nominal empêche la substitution accidentelle de types qui se ressemblent, ce qui explique en partie pourquoi le système de ReScript est sûr là où celui de TypeScript est délibérément non sûr.

Pourquoi Deno n'est-il pas considéré comme une alternative à TypeScript dans cette comparaison ?

Deno est un runtime JavaScript et TypeScript, et non un système de types superposé à JavaScript. Il exécute TypeScript directement en embarquant le compilateur TypeScript, ce qui en fait un dépendant de TypeScript plutôt qu'un remplaçant. Une véritable alternative doit soit vérifier les types dans le code source JavaScript, soit compiler un langage typé vers JavaScript. Ce même raisonnement exclut Dart et Kotlin/JS, qui sont des langages distincts ciblant JavaScript comme l'un de leurs backends de compilation parmi d'autres.

Le passage à TypeScript 7.0 casse-t-il les projets JavaScript typés avec JSDoc ?

En grande partie non, mais TypeScript 7.0, basé sur Go, a réécrit de zéro la vérification de types JavaScript et supprimé quelques balises JSDoc peu utilisées — spécifiquement @enum et @constructor, que la version 7.0 ne reconnaît plus. Les projets qui s'appuient sur ces balises doivent les migrer vers des patterns supportés. Les balises courantes comme @param, @returns, @typedef et @template continuent de fonctionner, de sorte que la plupart des bases de code typées en JSDoc restent compatibles sans modification. TypeScript 7.0 est la version stable depuis juillet 2026 ; exécutez votre projet avec cette version pour identifier précisément les différences.