Donnons des types plus précis à l’IA comme aux humains : une règle ESLint TypeScript personnalisée pour repérer les types de retour déclarés plus larges que l’implémentation

Quand on parcourt une base de code TypeScript,
on voit assez souvent des cas où l’implémentation d’une fonction retourne des valeurs plus étroites, tandis que son type de retour reste plus large.

Par exemple, un code comme celui-ci.

type Status = "idle" | "loading" | "error";  
  
function getStatus(isLoading: boolean): Status {  
  if (isLoading) return "loading";  
  return "idle";  
}  

La déclaration de type inclut error, mais l’implémentation réelle ne retourne que idle et loading.

Ce genre de code est valide du point de vue de TypeScript, mais
il peut conduire à laisser en place des membres de type de retour devenus inutilisés après un refactoring,
ou à conserver durablement une déclaration de type de retour plus large que l’implémentation.

En pratique, j’ai remarqué que ce type de cas apparaît souvent dans des situations comme :
• un membre d’union restant après un refactoring
• une annotation de type manuelle qui ne correspond plus à l’implémentation
• des annotations de type un peu trop lâches générées par une IA

J’ai donc créé une règle ESLint TypeScript personnalisée qui détecte les types de retour déclarés plus largement que l’implémentation.

https://github.com/minseong0324/eslint-plugin-no-misleading-return-type

Elle cible par exemple des cas comme :
• certains membres d’un type union ne sont plus jamais retournés
• le type est string, mais l’implémentation ne retourne en réalité qu’une union plus étroite de littéraux
• le type est Record<string, string>, mais l’implémentation retourne en réalité un objet as const avec des clés spécifiques
• etc.

L’idée n’est pas de dire « n’écrivons plus de types de retour », mais plutôt de
mettre en place un garde-fou qui pousse à revérifier si le type de retour déclaré correspond vraiment à l’implémentation.

Il reste encore des cas complexes non pris en charge et des points à améliorer,
mais je l’ai créé en me disant qu’à mesure que la vitesse de génération de code augmente à l’ère de l’IA, on a de plus en plus besoin de mécanismes capables de détecter automatiquement ce genre de dérive de types.

Vos retours sont les bienvenus.

[kwan03240324]

Ce qui m’intrigue particulièrement, c’est de savoir jusqu’où considérer qu’il s’agit d’un type de retour volontairement élargi, et à partir de quand le considérer comme un type de retour en décalage avec l’implémentation.