Démosles tipos más precisos a la IA y a las personas: una regla personalizada de TypeScript ESLint para detectar tipos de retorno declarados más amplios que la implementación

Cuando revisas un codebase de TypeScript,
a menudo te encuentras con casos donde la implementación de una función devuelve un valor más estrecho, pero el tipo de retorno sigue quedando más amplio.

Por ejemplo, un código así.

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

En la declaración de tipos incluso se incluye error, pero la implementación real solo devuelve idle y loading.

Este tipo de código es válido desde la perspectiva de TypeScript, pero
después de un refactor pueden quedar miembros del tipo de retorno que ya no se usan,
o puede mantenerse una declaración de tipo de retorno más amplia que la implementación.

En la práctica, sentí que estos casos aparecen con frecuencia en situaciones como
• miembros de una unión que quedaron después de un refactor
• declaraciones manuales de tipos que ya no coinciden con la implementación
• anotaciones de tipos algo laxas generadas por IA

Así que
creé una regla personalizada de TypeScript ESLint para detectar tipos de retorno declarados más amplios que la implementación.

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

Por ejemplo, está enfocada en casos como estos.
• algunos miembros de un tipo union ya no se devuelven
• el tipo es string, pero la implementación real solo devuelve una unión más estrecha de literales
• el tipo es Record<string, string>, pero la implementación real devuelve un objeto as const con keys específicas
• etc.

La intención no es “dejemos de escribir tipos de retorno”, sino
poner una barrera de seguridad que nos haga revisar otra vez si el tipo de retorno declarado realmente coincide con la implementación.

Todavía hay casos complejos que no soporta y partes que deben mejorarse,
pero sentí que, en la era de la IA, mientras más rápido se genera código, más necesitamos mecanismos que detecten automáticamente este tipo de deriva de tipos.

Se agradece el feedback.

[kwan03240324]

Lo que me intriga especialmente es hasta qué punto debe considerarse un tipo de retorno intencionalmente amplio, y a partir de dónde debe verse como un tipo de retorno que no coincide con la implementación.