AI और इंसानों को अधिक सटीक types दें: implementation से अधिक व्यापक रूप से घोषित return types को पकड़ने वाला TypeScript ESLint custom rule

TypeScript codebase को देखते समय अक्सर ऐसे मामले मिलते हैं,
जहां function implementation वास्तव में अधिक संकीर्ण value लौटाता है, लेकिन return type उससे अधिक व्यापक बना रहता है.

उदाहरण के लिए, ऐसा code:

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

Type declaration में error भी शामिल है, लेकिन वास्तविक implementation केवल idle और loading लौटाता है.

TypeScript के नज़रिए से ऐसा code वैध है,
लेकिन refactoring के बाद अब उपयोग में न आने वाले return type members बचे रह सकते हैं,
या implementation से अधिक व्यापक return type declaration लगातार बनी रह सकती है.

व्यवहार में मुझे लगा कि ऐसे मामले अक्सर
• refactoring के बाद बचे union members
• implementation से असंगत manual type declarations
• AI द्वारा बनाए गए कुछ ढीले type annotations

जैसी स्थितियों में पैदा होते हैं.

इसलिए
implementation से अधिक व्यापक रूप से घोषित return types को detect करने वाला TypeScript ESLint custom rule बनाया है.

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

उदाहरण के लिए, यह ऐसे मामलों को target करता है:
• union type के कुछ members अब लौटाए ही नहीं जाते
• type string है, लेकिन वास्तविक implementation केवल अधिक संकीर्ण literal union लौटाता है
• type Record<string, string> है, लेकिन वास्तविक implementation specific keys वाला as const object लौटाता है
• आदि

इरादा यह नहीं है कि “return type लिखना ही बंद कर दें”,
बल्कि ऐसा guardrail देना है जो फिर से देखने पर मजबूर करे कि घोषित return type वास्तव में implementation से मेल खाता है या नहीं.

अभी कुछ जटिल cases ऐसे हैं जिनका support नहीं है और कुछ हिस्सों में सुधार की गुंजाइश भी है,
लेकिन AI के दौर में code generation की रफ्तार जितनी बढ़ेगी, ऐसे type drift को अपने-आप पकड़ने वाली व्यवस्थाओं की ज़रूरत उतनी ही अधिक लगेगी — इसी सोच के साथ इसे बनाया है.

फ़ीडबैक का स्वागत है.

[kwan03240324]

मुझे खास तौर पर यह जानने की जिज्ञासा है कि किस सीमा तक इसे जानबूझकर दिया गया व्यापक return type माना जाए, और किस बिंदु से इसे implementation से मेल न खाने वाला return type समझा जाए।