00 - Le gap entre theorie et projet réel
Ce que tu vas apprendre
- Pourquoi connaître les types ne suffit pas pour un projet réel
- Les décisions pratiques que la theorie ne couvre pas
- Ce que cette serie couvre et comment elle s'articule avec les deux précédentes
Prerequisites
Avoir termine les series TypeScript — le système de types et TypeScript — types avances.
Le dev qui connaissait tous les types
L'annee dernière, j'ai travaille avec un dev qui connaissait TypeScript sur le bout des doigts. Conditional types, mapped types, infer, variance — il pouvait tout expliquer au tableau. Quand on a commence le projet ensemble, il a écrit un système de types genial pour l'API. Des generics elegants, des branded types pour les IDs, des discriminated unions pour les erreurs.
Le problème : personne dans l'équipe n'arrivait a le lire. Le tsconfig avait des options contradictoires. Les types etaient dans un seul fichier de 800 lignes. La validation runtime n'existait pas (il faisait confiance a ses types pour "protéger" les donnees de l'API). Et quand un junior a voulu ajouter un endpoint, il a mis deux heures a comprendre la structure.
Connaitre les types et savoir les appliquer dans un projet, c'est deux competences différentes. La première est technique, la deuxieme est du craft.
Ce que la theorie ne couvre pas
Les deux series précédentes t'ont appris le système de types. Cette serie répond aux questions que la theorie laisse ouvertes :
- Quelles options activer dans le tsconfig et pourquoi ?
- Comment valider les donnees aux frontieres (API, env, input) ?
- Ou mettre les types dans l'arborescence du projet ?
- Comment typer les composants React sans que ca devienne illisible ?
- Comment interagir avec Prisma ou Drizzle sans perdre le typage ?
- Comment migrer un projet JavaScript existant sans tout casser ?
- Comment savoir si tes types ralentissent le compilateur ?
Chaque article est un guide concret avec des exemples tires de vrais projets. Pas de theorie abstraite — que des décisions et des patterns applicables.
Ce que couvre cette serie
| # | Article | Contenu |
|---|---|---|
| 01 | tsconfig en profondeur | strict, paths, moduleResolution, verbatimModuleSyntax |
| 02 | Zod : validation runtime | Schemas, inference, intégration API |
| 03 | Variables d'environnement type-safe | Zod + process.env, t3-env |
| 04 | Organiser ses types dans un projet | Conventions, fichiers, colocation |
| 05 | Typer une API REST | Request, response, erreurs, client type-safe |
| 06 | Error handling type | Result pattern, erreurs discriminees |
| 07 | Types avec React | Composants, hooks, context, refs |
| 08 | Types avec les ORMs | Prisma, Drizzle, type-safe queries |
| 09 | Decorateurs natifs (TS 5+) | Stage 3 decorators, metadata |
| 10 | Generics contraints dans les libs | Écrire des API reutilisables et type-safe |
| 11 | Déclaration files (.d.ts) | Quand et comment les écrire, publier un package |
| 12 | Monorepo et partage de types | Packages partages, barrel files, re-exports |
| 13 | Migration JS → TS progressive | allowJs, strict incremental, any → unknown |
| 14 | Performance du compilateur | Types lents, --generateTrace, optimiser |
| 15 | Types et tests | Mocks types, fixtures, expect-type |
| 16 | Glossaire | Tous les termes de la serie |
Tous les exemples de code sont bases sur le stack que j'utilise sur paltemps.fr : Bun, Elysia, React, Prisma, dans un monorepo TypeScript.
Résumé
- Connaitre les types et les appliquer dans un projet sont deux competences distinctes
- Cette serie couvre les décisions pratiques : tsconfig, validation, organisation, migration, performance
- Chaque article est un guide concret avec des patterns applicables
Article suivant : 01 - tsconfig en profondeur
Sources
- TypeScript Documentation
- Total TypeScript - Tips par Matt Pocock