AI und Menschen präzisere Typen geben: Eine benutzerdefinierte TypeScript-ESLint-Regel, die breiter deklarierte Rückgabetypen als die Implementierung erkennt

Wenn man sich größere TypeScript-Codebasen ansieht,
sieht man häufig Fälle, in denen eine Funktion tatsächlich einen engeren Wert zurückgibt, der deklarierte Rückgabetyp aber breiter geblieben ist.

Ein Beispiel wäre etwa dieser Code.

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

In der Typdeklaration ist sogar error enthalten, die tatsächliche Implementierung gibt aber nur idle und loading zurück.

Aus Sicht von TypeScript ist solcher Code gültig,
kann aber dazu führen, dass nach Refactorings Rückgabetyp-Mitglieder zurückbleiben, die nicht mehr verwendet werden,
oder dass eine breiter als die Implementierung formulierte Rückgabetyp-Deklaration dauerhaft bestehen bleibt.

In der Praxis hatte ich den Eindruck, dass solche Fälle häufig in Situationen entstehen wie
• Union-Member, die nach einem Refactoring übrig geblieben sind
• manuell deklarierte Typen, die nicht mehr zur Implementierung passen
• etwas zu lockere Typannotationen, die von AI generiert wurden

Deshalb habe ich eine benutzerdefinierte TypeScript-ESLint-Regel gebaut, die Rückgabetypen erkennt, die breiter deklariert sind als die Implementierung.

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

Sie zielt zum Beispiel auf Fälle wie diese ab.
• einzelne Member eines Union-Typs werden nicht mehr zurückgegeben
• der Typ ist string, die tatsächliche Implementierung gibt aber nur eine engere Literal-Union zurück
• der Typ ist Record<string, string>, die tatsächliche Implementierung gibt aber ein as const-Objekt mit bestimmten Keys zurück
• usw.

Die Absicht ist nicht zu sagen: „Verwendet keine Rückgabetypen“,
sondern eine Guardrail einzuziehen, die dazu bringt, noch einmal zu prüfen, ob der deklarierte Rückgabetyp wirklich mit der Implementierung übereinstimmt.

Es gibt noch komplexe Fälle, die bisher nicht unterstützt werden, und auch sonst bleibt noch Verbesserungsbedarf,
aber je schneller Code im AI-Zeitalter generiert wird, desto mehr braucht es meiner Meinung nach Mechanismen, die solchen Type Drift automatisch aufspüren.

Feedback ist willkommen.

[kwan03240324]

Mich interessiert vor allem, bis wohin man einen absichtlich allgemeinen Rückgabetyp annimmt und ab wann man ihn als einen Rückgabetyp betrachtet, der von der Implementierung abweicht.