TypeScript'e geçiş: JavaScript'te tip güvenliği

Frontend kod tabanlarım büyüdükçe bir örüntü fark ettim: bir fonksiyonun parametresine yanlış tip geçmek, yanlış bir property okumak gibi hatalar runtime’da ortaya çıkıyor; üstelik bazen çok geç. PHP’de 7.x ile birlikte daha sıkı tip bildirimleri kullandığımda bunun büyük bir güven verdiğini yaşamıştım. JavaScript tarafında da aynı güvenceyi istiyordum. Bu yüzden TypeScript’e geçiş kararını verdiğimde hazırlıklı hissediyordum — ama gerçek deneyim beklediğimden farklıydı.

TypeScript nedir?

TypeScript, JavaScript’e statik tip sistemi ekleyen ve Microsoft tarafından geliştirilen bir superset dilidir. Yazdığınız TypeScript kodu derlenerek sıradan JavaScript’e çevriliyor; tarayıcı ya da Node.js için ayrı bir şey gerekmez. TypeScript yalnızca yazma anında size söyler: “bu değer string bekliyor, number veriyorsunuz.”

Geçişe nereden başladım?

Mevcut bir projeye TypeScript eklemek için en az acılı yol, tsconfig.json’da "strict": false ile başlayıp kademeli olarak arttırmak. Tüm dosyaları .js’ten .ts’e değiştirmek zorunda değilsiniz; allowJs: true ile iki formatı karıştırabilirsiniz.

Yeni bir component yazmaya karar verdiğimde doğrudan TypeScript ile başladım:

interface User {
  id: number;
  name: string;
  email: string;
  role: 'admin' | 'editor' | 'viewer';
}

function formatUserLabel(user: User): string {
  return `${user.name} <${user.email}>`;
}

// Bu satır derleme anında hata verir:
// formatUserLabel({ id: 1, name: 'Test' }); // email eksik

PHP’de tip bildirimleri method imzasında; TypeScript’te ise interface veya type alias ile veri şekillerini tanımlıyorsunuz. Başta tuhaf geldi ama hızla alıştım.

En değerli olduğu anlar

Refactor güvencesi. Bir interface’in alanını yeniden adlandırdığınızda, onu kullanan her yerde TypeScript hata veriyor. JavaScript’te bu hatayı testler yakalamasa runtime’da keşfederdiniz.

IDE entegrasyonu. TypeScript ile birlikte autocomplete çok daha güçleniyor. user. yazdığınızda hangi alanların var olduğunu biliyor. Parametre tiplerini yanlış girdiğinizde anında kırmızı çizgi görüyorsunuz.

Takım içi iletişim. Interface’ler, bir fonksiyonun ne beklediğini ve ne döndürdüğünü açıkça söyleyen canlı dokümantasyon gibi davranıyor.

Sürtünme noktaları

TypeScript’in öğrenme eğrisi, syntax’tan çok tip sisteminin kendisinden geliyor. Basit durumlar kolayca ifade ediliyor. Ama gerçek dünyada:

// Dış API'den gelen yanıt tipi belirsizse:
const response = await fetch('/api/users');
const data = await response.json(); // 'any' tip — güvence yok

Dış veriyi tip sistemine sokmak için type guard ya da as type assertion kullanmak gerekiyor. Bu alan hâlâ benim için öğrenme sürecinde.

function isUser(obj: unknown): obj is User {
  return typeof obj === 'object' && obj !== null && 'id' in obj;
}

Ayrıca her üçüncü parti kütüphane TypeScript tiplerine sahip değil. @types/... paketleri çoğu popüler kütüphaneyi kapsıyor ama bazen any ile çalışmak zorunda kalıyorsunuz.

strict modu: erken mi geç mi açmalı?

"strict": false ile başlamak geçişi kolaylaştırıyor, ama bir tuzak var: strict kapalıyken TypeScript sizi gerçek hatalardan da korumayabiliyor. strictNullChecks olmadan nullable hataları yakalanmıyor; noImplicitAny olmadan any tip sessizce yayılıyor. Yeni dosyalarda hemen strict: true ile başlamak, sonradan kapsamı genişletmekten çok daha az acı verdi. Eski dosyaları kademe kademe sıkılaştırmak ise ayrı bir iş — ama yapılabilir.

JavaScript’i bırakmak mı?

TypeScript, JavaScript’in bir alternatifi değil; üstüne oturan bir araç. Tüm JavaScript kodunuz geçerli TypeScript. Fark şu: TypeScript sizi yavaşlatmıyor, aksine büyük kod tabanlarında hız kazanmanızı sağlıyor. Küçük bir script için tip bildirimleri fazlalık olabilir; ama birkaç geliştirici, yüzlerce dosya içeren bir proje düşünüldüğünde trade-off açıkça TypeScript lehine.

PHP backend’imde tip güvenliğinin verdiği konforu frontend’de de yaşıyorum artık. Geçişin başlangıç maliyeti var ama uzun vadede değerli.