tsgolint v7 livre un linting sensible aux types écrit en Go

Le linting sensible aux types (type-aware linting) pour TypeScript dispose désormais d'une implémentation stable écrite en Go. Le projet Oxc a annoncé tsgolint v7.0.2000 le 22 juillet 2026, et l'article d'InfoQ du 11 septembre 2026 lui a valu une attention plus large. Il couvre 59 des 61 règles sensibles aux types de typescript-eslint.

La distinction compte plus qu'il n'y paraît. La plupart des règles de lint n'ont besoin que de lire la forme de votre code : un point-virgule manquant, une variable inutilisée. Les règles sensibles aux types doivent savoir ce que les choses sont réellement. Demander si une promesse est un jour attendue avec await revient à interroger le vérificateur de types, et le vérificateur de types est la partie lente.

C'est pourquoi ces règles ont la réputation de faire durer un passage de lint plusieurs minutes. tsgolint ne réimplémente pas le vérificateur de types pour éviter ce coût. Il construit de vrais programmes TypeScript au-dessus de typescript-go, que le README GitHub du projet décrit comme « l'implémentation TypeScript de Microsoft », et vise TypeScript 7, nom de code Project Corsa.

Les propres chiffres du projet ne concordent pas

C'est ici que le compte rendu devient délicat, et il vaut mieux le dire franchement que de retenir le chiffre le plus flatteur.

Le billet du blog Oxc donne des temps détaillés sur un Apple M4 Pro à 12 cœurs, en comparaison avec ESLint plus typescript-eslint sur des configurations équivalentes. Ils montrent une amélioration de 12 à 18 fois : microsoft/vscode passe de 83,2 secondes à 6,96 secondes, microsoft/typescript de 27,2 à 1,94, typeorm de 13,2 à 0,75 et vuejs/core de 12,3 à 0,95.

Le README du projet résume ses benchmarks autrement. Il rapporte de 22 à 34 fois sur les mêmes quatre dépôts et affirme que l'outil est « 20-40x plus rapide qu'ESLint + typescript-eslint sur les grands dépôts ».

Les deux affirmations viennent du même projet, à propos du même outil, face à la même comparaison. L'article d'InfoQ cite la fourchette basse. Nous n'avons vu aucune explication de cet écart, et aucun des deux chiffres n'a été reproduit de façon indépendante. Considérez les 12-18x du blog comme le chiffre dont le calcul est visible, et mesurez votre propre dépôt avant de bâtir un budget sur l'un ou l'autre.

Le blog explique bien d'où viennent les gains : « des chemins rapides qui évitent les requêtes coûteuses au vérificateur de types quand la syntaxe donne déjà la réponse ». Une règle, dit-il, s'est révélée « 35 fois plus rapide sur VS Code ».

Version 7 d'un projet qui n'a jamais eu de version 1

tsgolint est passé directement d'une lignée expérimentale 0.x à une v7 stable, ce qui ressemble à un bond marketing et n'en est pas un.

La version suit désormais le compilateur qu'elle embarque. Dans v7.0.2000, le 7.0.2 est la version de TypeScript, et le compteur final est le numéro de correctif propre à tsgolint, remis à zéro chaque fois que la version de TypeScript change. InfoQ cite le raisonnement : « tsgolint est désormais versionné par rapport au compilateur qu'il embarque ». L'effet pratique est que la chaîne de version vous dit quel vérificateur de types vous obtenez.

	Détail
Version stable	v7.0.2000, 22 juillet 2026
TypeScript suivi	v7.0.2
Règles implémentées	59 sur 61, contre 43 à l'alpha de décembre
TypeScript minimum	7.0
Installation	pnpm add -D oxlint oxlint-tsgolint@7
Exécution	pnpm oxlint --type-aware

Le code a commencé comme un prototype au sein de l'organisation typescript-eslint, créé par le contributeur auvred, et le fork d'Oxc le poursuit avec la permission de cet auteur.

Ce que cela signifie pour les développeurs

La contrainte à vérifier en premier est TypeScript 7. Le linting sensible aux types exige ici la 7.0 ou plus récente, et InfoQ note que certaines options tsconfig héritées et certaines fonctionnalités de TypeScript 6 ne sont toujours pas prises en charge. Si votre build est sur TypeScript 6, c'est un chantier à planifier, pas quelque chose à adopter cet après-midi.

Si vous êtes déjà sur la 7, l'expérience honnête est un seul passage chronométré. Installez les deux paquets, lancez pnpm oxlint --type-aware sur votre dépôt et comparez avec votre invocation ESLint actuelle. Votre propre chiffre vaut plus que n'importe quel tableau de benchmarks, et c'est un cas où les chiffres publiés ne sont même pas cohérents entre eux.

Les deux règles manquantes comptent plus que le décompte ne le suggère. Vérifiez si l'une des deux qui n'ont pas abouti est une règle sur laquelle votre équipe s'appuie. Une suite de lint qui tourne 12 fois plus vite mais abandonne en silence la règle qui attrape votre classe de bogues est un mauvais échange.

Il y a là un schéma plus large qui mérite d'être noté. Réécrire l'outillage des développeurs dans un langage compilé pour gagner en vitesse est devenu routinier cette année. Debian Code Search a abandonné sa dernière dépendance C pour du Go pur et a égalé la version C. L'auteur de l'éditeur de liens mold est en train de le réécrire de C++ en Rust. Ce qui distingue tsgolint, c'est qu'il n'a pas réécrit la partie difficile. Il a embarqué le propre compilateur de Microsoft et optimisé autour, ce qui est une façon bien moins coûteuse d'être correct.