00 - TypeScript ne se résumé pas a ajouter : string
Ce que tu vas apprendre
- Pourquoi la plupart des devs n'utilisent que 10% du système de types
- Ce que tu rates en te limitant aux annotations basiques
- Ce que cette serie couvre et comment elle est organisee
Prerequisites
Savoir lire du TypeScript. Avoir deja écrit du code avec des types basiques (string, number, boolean, interfaces). Si tu debutes en TS, commence par la doc officielle et reviens ici apres.
Le any qui revient toujours
Il y a quelques mois, j'ai fait une revue de code sur un projet client. Une app Next.js, Prisma, le stack classique. Le dev avait mis TypeScript partout. Fichiers .ts, .tsx, interfaces pour les composants, types pour les props React. Sur le papier, le projet etait "type".
Sauf que quand j'ai ouvert le code, j'ai compte 74 occurrences de any. Pas dans du code legacy. Dans du code écrit la semaine d'avant.
Le dev m'a dit un truc que j'entends souvent : "TypeScript me ralentit, des que le type devient complique je mets any et je reviens dessus plus tard." Le "plus tard" n'arrive jamais. Et le any se propage. Tu passes un any a une fonction, elle retourne un any, tu le passes a une autre fonction, et en trois appels tu as perdu tout le typage de ta chaîne. Le compilateur ne dit plus rien. Tu es revenu a du JavaScript avec une fausse sensation de sécurité.
Le problème, c'est pas le dev. C'est que personne ne lui a explique comment fonctionne le système de types au-delà des bases.
TypeScript : un langage dans le langage
Ce que la plupart des devs utilisent de TypeScript :
typescriptconst name: string = "Nicolas"
const age: number = 31
interface User {
id: number
name: string
email: string
}
function getUser(id: number): User {
// ...
}
C'est utile. Ca attrape des erreurs. Mais c'est comme utiliser un moteur V8 pour faire du 30 km/h en ville.
Le système de types de TypeScript est un langage a part entière. Il a ses propres variables (les generics), ses conditions (extends ? :), ses boucles (mapped types), sa recursivite (types recursifs), ses fonctions (utility types). Tu peux écrire de la logique qui s'exécuté au moment de la compilation, pas au runtime.
Quand tu maitrises ce langage, tu peux faire des choses que les annotations basiques ne permettent pas. Par exemple, une fonction qui retourne un type différent selon ce qu'on lui passe :
typescriptfunction parse<T extends "string" | "number">(
value: string,
type: T
): T extends "string" ? string : number {
// ...
}
const a = parse("42", "number") // type: number
const b = parse("hello", "string") // type: string
Le compilateur sait, avant meme que le code tourne, que a est un number et b est un string. Pas de cast, pas de any, pas de as. Le type decoule de l'usage.
Ce que ca change concrètement
Quand le système de types est bien utilise, il attrape des bugs que les tests ne trouvent pas. Pas des bugs de logique métier, mais des bugs de contrat : une fonction appelee avec le mauvais argument, un champ oublie dans un objet, un cas non gere dans un switch.
Sur paltemps.fr, j'ai un système de notifications typees avec des discriminated unions. Chaque type de notification (email, SMS, push) a un payload différent. Le compilateur m'oblige a gerer chaque cas. Si j'ajoute un nouveau type de notification, le compilateur me montre tous les endroits du code ou je dois ajouter la gestion de ce nouveau type. Pas besoin de chercher a la main.
Selon le State of JS 2024, 78% des devs ecrivent maintenant plus de TypeScript que de JavaScript. Mais utiliser TypeScript et maîtriser son système de types, c'est deux choses différentes. L'enquête Stack Overflow Developer Survey 2024 place TypeScript dans le top 5 des langages les plus utilises, mais les questions les plus posees sur Stack Overflow restent "how to fix type error" et "when to use any".
Ce que couvre cette serie
Cette première sous-serie pose les fondations du système de types. Tout ce que tu dois comprendre avant d'attaquer les types avances.
| # | Article | Contenu |
|---|---|---|
| 01 | any, unknown, never |
Le trio que personne ne comprend vraiment |
| 02 | Inference, widening, narrowing | Quand annoter et quand laisser TS deviner |
| 03 | Valeurs vs références | Copies, mutations, spread traps |
| 04 | Immutabilite et readonly |
Readonly, as const, Object.freeze |
| 05 | Egalite structurelle vs referentielle | Pourquoi === ment sur les objets |
| 06 | Generics | Les vrais, pas juste Array<T> |
| 07 | Discriminated unions | Le pattern le plus utile de TypeScript |
| 08 | Type guards | is, asserts, instanceof, in |
| 09 | Null safety | strictNullChecks, optional chaining, NonNullable |
| 10 | Utility types | Partial, Pick, Omit, Record et les autres |
| 11 | Union vs intersection | Quand utiliser ` |
| 12 | Enums vs unions litterales | Et pourquoi je déconseillé les enums |
| 13 | Tuples | Labeled, variadic, rest éléments |
| 14 | keyof, typeof, index access types | Extraire des types depuis d'autres types |
| 15 | Glossaire | Tous les termes de la serie |
Si tu as suivi la serie Design patterns en TypeScript, tu as deja croise des generics et des interfaces. Cette serie reprend ces concepts a la racine et va plus loin. Et si tu viens de la serie SQL avance, tu verras comment typer proprement les résultats de tes requêtes brutes avec les outils qu'on couvre ici.
Apres cette serie, deux autres suivent : TypeScript — types avances (mapped types, conditional types, variance, pattern matching) et TypeScript — en pratique (Zod, typer une API, React, ORMs, migration JS vers TS).
Résumé
- La majorite des devs TypeScript n'utilisent qu'une fraction du système de types, ce qui mene a des
anypartout et un faux sentiment de sécurité - Le système de types est un langage a part entière avec ses propres variables, conditions, boucles et recursivite
- Un typage bien fait attrape des categories entières de bugs au moment de la compilation
- Cette serie couvre les 15 concepts fondamentaux du système de types, de
anyvsunknownjusqu'aux index access types
Article suivant : 01 - any, unknown, never : le trio que personne ne comprend