TypeScript utilise un typage structurel. Qu'est-ce que ça veut dire en pratique, et où est-ce que ça vous mord ?

Le typage structurel veut dire que la compatibilité se décide sur la forme, pas sur le nom déclaré, donc tout objet ayant les bonnes propriétés satisfait le type. Ça rend les types peu coûteux et composables, mais ça veut aussi dire que deux concepts sans rapport ayant la même forme sont interchangeables, donc un userId de type string peut être passé là où on attend un orderId de type string. La correction habituelle est un type marqué (branded type) ou un petit wrapper qui donne à la valeur une forme distincte.

Ça veut dire que TypeScript compare des formes, pas des noms, donc si quelque chose a les bonnes propriétés c'est assignable, quelle que soit sa provenance. C'est surtout un cadeau, puisque ça fait ressembler les types à de la documentation plutôt qu'à du cérémonial. Là où ça mord, c'est quand deux types ont la même forme mais désignent des concepts différents. Tous mes identifiants étaient de simples strings, donc passer un identifiant utilisateur à une fonction qui attendait un identifiant de commande compilait parfaitement et échouait en production. J'ai corrigé ça avec des types marqués, une intersection avec une étiquette unique que seule une fonction de construction peut produire, pour que le compilateur cesse de les traiter comme identiques. L'autre piège, c'est que les types sont effacés, donc rien ne vérifie la réponse d'une API à l'exécution. Je parse tout ce qui franchit une frontière avec un validateur de schéma et je laisse le type inféré en découler, ce qui fait que le type et les vraies données ne peuvent pas diverger. Et je sais que le contrôle des propriétés excédentaires ne s'applique qu'aux littéraux d'objet frais, ce qui explique beaucoup de confusion sur le fait qu'un champ en trop est parfois une erreur et parfois non.