Memberi Tipe yang Lebih Akurat untuk AI dan Manusia: Aturan Kustom TypeScript ESLint untuk Menangkap Tipe Return yang Dideklarasikan Lebih Luas dari Implementasinya

Saat melihat codebase TypeScript,
sering kali kita menemukan kasus di mana implementasi fungsi mengembalikan nilai yang lebih sempit, tetapi tipe return-nya tetap dibiarkan lebih luas.

Contohnya seperti kode berikut.

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

Deklarasi tipenya masih mencakup error, tetapi implementasi sebenarnya hanya mengembalikan idle dan loading.

Kode seperti ini valid dari sudut pandang TypeScript,
namun bisa menimbulkan masalah seperti member tipe return yang tidak lagi digunakan setelah refactoring tetap tertinggal,
atau deklarasi tipe return yang lebih luas dari implementasi terus dipertahankan.

Dalam praktiknya, saya merasa kasus seperti ini sering muncul dalam situasi seperti
• union member yang tersisa setelah refactoring
• deklarasi tipe manual yang tidak lagi selaras dengan implementasi
• type annotation yang agak longgar hasil generasi AI

Karena itu,
saya membuat aturan kustom TypeScript ESLint untuk mendeteksi tipe return yang dideklarasikan lebih luas daripada implementasinya.

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

Misalnya, aturan ini menargetkan kasus seperti berikut.
• sebagian member dari union type tidak lagi dikembalikan
• tipenya string, tetapi implementasi sebenarnya hanya mengembalikan literal union yang lebih sempit
• tipenya Record<string, string>, tetapi implementasi sebenarnya mengembalikan objek as const dengan key tertentu
• dan lain-lain

Tujuannya bukan “jangan menulis tipe return”, melainkan
menyediakan guardrail yang mendorong kita untuk memeriksa kembali apakah tipe return yang dideklarasikan benar-benar sesuai dengan implementasinya.

Masih ada kasus-kasus kompleks yang belum didukung dan bagian yang perlu diperbaiki,
namun di era AI, ketika kecepatan generasi kode semakin tinggi, saya merasa semakin dibutuhkan mekanisme untuk otomatis menangkap type drift seperti ini.

Masukan sangat diterima.

[kwan03240324]

Yang paling membuat saya penasaran adalah, sampai sejauh mana kita harus menganggapnya sebagai tipe pengembalian luas yang memang disengaja, dan mulai dari titik mana kita harus menganggapnya sebagai tipe pengembalian yang tidak selaras dengan implementasi.