TypeScript Strict Mode: Neden ve Nasıl Açmalısınız?

TypeScript'i kullanmak, tip güvenliğine sahip olmak anlamına gelmez. strict kapalıyken derleyici; tipi belirtilmemiş parametreleri sessizce any kabul eder, null ve undefined değerlerini her tipe atanabilir sayar ve üretimde "Cannot read properties of undefined" hatasına dönüşecek birçok durumu görmezden gelir. Bu yazıda strict bayrağının neleri açtığını, onun ötesinde hangi bayrakların değerlendirilmeye değer olduğunu ve mevcut bir kod tabanında strict moda ekibi durdurmadan nasıl geçilebileceğini ele alıyoruz.

strict Tek Bir Ayar Değil, Bir Ayar Ailesi

tsconfig.json içindeki "strict": true, bir grup denetimi birlikte açan bir kısayoldur. Güncel TypeScript sürümlerinde bu aile şunları içerir:

• noImplicitAny: Tipi çıkarılamayan değişken ve parametrelerin örtük olarak any olmasını hata sayar.
• strictNullChecks: null ve undefined'ı ayrı tipler olarak ele alır. En çok hata yakalayan ve geçişte en çok değişiklik gerektiren bayrak genellikle budur.
• strictFunctionTypes: Fonksiyon parametrelerinin tip uyumluluğunu daha sıkı denetler.
• strictBindCallApply: bind, call ve apply çağrılarının argümanlarını denetler.
• strictPropertyInitialization: Sınıf alanlarının constructor'da başlatıldığını denetler.
• noImplicitThis: Tipi belirsiz this kullanımını hata sayar.
• useUnknownInCatchVariables: catch bloğundaki hata değişkenini any yerine unknown yapar.
• alwaysStrict: Dosyaları JavaScript'in strict modunda derler.
• strictBuiltinIteratorReturn: TypeScript 5.6 ile eklenen, yerleşik iteratörlerin dönüş tipini daha doğru belirleyen denetim.

Yeni TypeScript sürümleri bu aileye yeni denetimler ekleyebilir. Bu yüzden TypeScript sürümünü yükseltmek, strict modda yeni hatalar görmenize yol açabilir; yükseltmeleri ayrı PR'larda yapmak bu hataları izole eder.

Strict'in Yakaladığı Tipik Hatalar

Bulunamayan kayıt

function musteriAdi(id: string) {
  const musteri = musteriler.find((m) => m.id === id);
  return musteri.ad.toUpperCase();
  // strictNullChecks: 'musteri' is possibly 'undefined'.
}

find eşleşme bulamazsa undefined döner. Strict kapalıyken bu kod derlenir ve hata ancak çalışma anında ortaya çıkar. Strict açıkken derleyici sizi bu durumu ele almaya zorlar: ya erken dönüş yaparsınız ya da bulunamama durumunda ne olacağına karar verirsiniz.

Catch bloğundaki bilinmeyen hata

try {
  await odemeAl(siparis);
} catch (hata) {
  // hata: unknown
  const mesaj = hata instanceof Error ? hata.message : String(hata);
  logger.error({ mesaj, siparisId: siparis.id });
}

JavaScript'te throw ile her şey fırlatılabilir; bir string, bir nesne, hatta undefined. unknown tipi, hata nesnesini kullanmadan önce gerçekten ne olduğunu kontrol etmeyi zorunlu kılar.

strict'in Dışında Kalan Değerli Bayraklar

Bazı denetimler strict ailesine dahil değildir ve ayrıca açılmaları gerekir:

• noUncheckedIndexedAccess: Dizi elemanlarına ve indeks imzalı nesnelere erişimin sonucuna undefined ekler. satirlar[0] artık Satir değil, Satir | undefined tipindedir. Gerçek bir hata sınıfını yakalar; karşılığında döngü ve dizi kodunda ek kontroller gerektirir.
• exactOptionalPropertyTypes: İsteğe bağlı bir alanın "hiç olmaması" ile "değerinin undefined olması" arasındaki farkı ayırt eder.
• noImplicitOverride: Üst sınıftaki bir metodu ezen metotların override anahtar kelimesiyle işaretlenmesini zorunlu kılar.
• noImplicitReturns ve noFallthroughCasesInSwitch: Bazı dallarda değer döndürmeyi unutan fonksiyonları ve break'i unutulmuş case bloklarını yakalar.

const satirlar: string[] = dosya.split("\n");
const baslik = satirlar[0];
// noUncheckedIndexedAccess açıkken: string | undefined

for (const satir of satirlar) {
  // for...of içinde satir: string (ek kontrol gerekmez)
}

Bu bayrakların ilk açılışta kod tabanında çok sayıda değişiklik gerektirmesi normaldir. Özellikle noUncheckedIndexedAccess'i, strict'e geçiş tamamlandıktan sonra ayrı bir adım olarak ele almak daha yönetilebilirdir.

Mevcut Bir Projede Kademeli Geçiş

Büyük bir kod tabanında strict'i tek seferde açmak, haftalarca süren ve sürekli çakışan bir dal demektir. Kademeli bir plan çok daha sürdürülebilirdir:

1. Mevcut durumu ölçün. Bayrakları tek tek açıp tsc --noEmit ile kaç hata çıktığını not edin. Hangi bayrağın ne kadar iş getirdiğini görmek sıralamayı belirler.
2. Bayrakları sırayla açın. "strict": true yerine önce tek tek bayrakları ekleyin. noImplicitAny ve strictNullChecks en çok değer sağlayan, genellikle de en çok iş çıkaran ikilidir.
3. Hata sayısını sabitleyin. CI'da hata sayısının artmasına izin vermeyen bir kontrol koyun. Böylece yeni kod eski sorunları büyütmez, mevcut sayı da her PR ile azalır.
4. Yeni kodu baştan strict yazın. Dosya veya dizin bazında strict denetim yapmaya izin veren araçlar (örneğin typescript-strict-plugin) ya da ayrı bir tsconfig ile yeni modüllerin baştan sıkı denetlenmesi sağlanabilir.
5. Bilinçli istisnaları işaretleyin. Hemen çözülemeyen yerlerde @ts-ignore yerine @ts-expect-error ve kısa bir açıklama kullanın. Altındaki hata düzeldiğinde bu yorum kendisi hata vereceği için unutulmaz.

typescript-eslint'in no-explicit-any ve no-non-null-assertion kuralları, strict'in kapattığı kapıların any ve ! operatörüyle arka kapıdan yeniden açılmasını önler.

Tipler Sınırda Biter: Çalışma Zamanı Doğrulaması

Strict mod derleme zamanındaki tutarlılığı garanti eder; dışarıdan gelen verinin gerçekten beklenen biçimde olduğunu garanti etmez. API yanıtları, form girdileri, JSON.parse sonuçları ve ortam değişkenleri çalışma zamanında beklenmedik biçimde gelebilir. Bu sınırlarda Zod veya Valibot gibi bir şema kütüphanesiyle doğrulama yapmak, tiplerin gerçekle örtüşmesini sağlar:

import { z } from "zod";

const Siparis = z.object({
  id: z.string(),
  tutar: z.number().nonnegative(),
  teslimTarihi: z.string().nullable(),
});

type Siparis = z.infer<typeof Siparis>;

const siparis = Siparis.parse(await yanit.json());

Aynı ilke otomatik üretilen tipler için de geçerlidir. OpenAPI, GraphQL ya da ORM şemalarından üretilen tipler, ancak dayandıkları şema kadar doğrudur. Strict mod bu tiplerdeki null olabilen alanları görünür kıldığı için genellikle faydalıdır; şema ile gerçek davranış arasında fark varsa bu fark da ilk kez görünür hâle gelir.

Sonuç

Strict mod, hataları kullanıcının ekranından derleyicinin çıktısına taşır. Geçişin maliyeti gerçektir; ama kademeli bir planla, CI'da sabitlenen bir hata sayısıyla ve yeni kodun baştan sıkı yazılmasıyla bu maliyet ekibi durdurmadan, küçük parçalar hâlinde ödenebilir. Ön yüzü ve arka yüzü aynı dilde yazılan TeksERP gibi projelerde bunun ek bir getirisi de var: Sunucu ile istemci arasında paylaşılan tipler, iki tarafın aynı veri sözleşmesine uymasını derleme anında denetler.