Réponse.

Historique de la question

TypeScript a été créé en mettant l'accent sur un développement sûr sans excès de types explicites : la plupart des types de variables, de paramètres et de valeurs retournées peuvent être automatiquement inférés par le compilateur. Le système d'inférence de types permet d'écrire un code presque comme en JavaScript, tout en conservant une typage strict, ce qui accélère considérablement le développement et réduit le nombre d'erreurs.

Problème

L'inférence de type ne garantit pas toujours qu'elle infère le type attendu par le développeur. Des situations se présentent où le type est trop large (any ou unknown) ou, au contraire, trop strict. Cela conduit soit à des restrictions excessives, soit à l'absence de vérification de types, ce qui est dangereux dans les deux cas.

Solution

TypeScript infère automatiquement le type sur la base de l'affectation ou de la valeur retournée par la fonction, si le type n'est pas explicitement spécifié. On peut contrôler l'inférence en indiquant explicitement le type, en utilisant des assertions de type, des génériques et des utilitaires spéciaux (ReturnType, Parameters, etc.). Travailler avec des structures complexes nécessite un contrôle particulier : si le type est compliqué ou peu évident, il vaut mieux le spécifier clairement.

Exemple de code :

let a = 5; // number (sera automatiquement inféré)

function sum(x = 4, y = 3) { // x: number, y: number
  return x + y; // return: number
}

// Erreur d'inférence de type
function getData(flag) {
  if (flag) return 123;
  // pas de retour dans l'autre branche — type de retour: number | undefined
}

// Il vaut mieux spécifier clairement :
function getData(flag: boolean): number | undefined {
  if (flag) return 123;
}

Caractéristiques clés :

TypeScript infère les types des variables à partir de l'initialisation et de la valeur.
Pour les fonctions et les objets, les types peuvent devenir trop larges sans indication explicite.
Pour les génériques et les structures complexes, il est préférable de toujours spécifier le type explicitement.

Questions pièges.

Vrai/Faux : L'inférence de type donne toujours le type attendu par le développeur

Faux. Parfois, le type est plus large ou plus étroit, en particulier pour les tableaux/objets/valeurs de retour union (number | undefined — une surprise fréquente).

Si l'on ne spécifie pas de type dans un objet, TypeScript conservera toujours la structure exacte

Non, sans as const, la structure sera "étendue" (widened), avec as const elle sera en lecture seule avec des types littéraux.

const obj = { kind: "duck" };
// obj: { kind: string }
const obj2 = { kind: "duck" } as const;
// obj2: { readonly kind: "duck" }

Si l'on ne spécifie pas de type pour un tableau, TS connaît toujours sa composition

Non, par défaut TypeScript rend le tableau aussi "large" que possible — par exemple, let arr = [1, 'a'] sera (string | number)[], et non un tuple.

Erreurs de type et anti-patterns

Compter sur l'inférence de types pour les paramètres de fonction (surtout pour les API) — les types peuvent changer lors des modifications.
Ne pas spécifier les types de retour des fonctions — difficile à maintenir.
Ne pas utiliser as const ou des types explicites pour les objets constants.

Exemple de la vie réelle

Cas négatif

Le backend retourne un objet réponse { data: [] }, le type n'étant pas spécifié explicitement, TypeScript infère le type data: any[]. À un moment donné, data devient un tableau de chaînes — l'erreur n'apparaît qu'en production.

Avantages :

Pas besoin d'écrire les types manuellement pour des cas simples.

Inconvénients :

Erreurs non évidentes avec des structures complexes.
L'inférence automatique peut "engloutir" le problème.

Cas positif

Dans le projet, il est toujours d'usage de spécifier explicitement les types des valeurs de retour des fonctions et des structures complexes, d'utiliser as const pour les constantes. Tout changement de structure est vérifié par le compilateur.