TypeScript Strict Mode: Type-Safe Stack ve Runtime Validation

TypeScript (strict mode) nedir?

TypeScript, JavaScript’e statik tip sistemi ekleyen açık kaynak bir programlama dilidir. Strict mode (tsconfig.json içinde strict: true flag’i), dilin en katı tip kontrol seviyesini aktive eder: null safety, implicit any yasağı, unused parameter kontrolleri gibi tüm güvenlik katmanları devreye girer. Gonet’te TypeScript strict mode, sadece syntax kontrolü değil, end-to-end type safety stratejisinin temelidir — API sözleşmesinden UI component prop’larına, veritabanı şemasından form validasyonuna her katman tip güvenli inşa edilir. Zod gibi runtime validation (çalışma zamanı doğrulama) kütüphaneleriyle entegrasyonu, statik tiplerin runtime’da da garanti edilmesini sağlar.

26 yıllık deneyimimizde şunu gördük: büyük ölçekli projelerde hatalar %70 oranında tip uyumsuzluklarından kaynaklanır. Strict mode bu hataları development aşamasında yakalar, Zod ise dış dünyadan gelen veriyi (API response, user input) tip güvenli şekilde parse eder.

Neden kritik?

JavaScript’in dinamik doğası esneklik sağlar, ancak ölçekte bakım maliyetini katlar. Production’da undefined is not a function hatası görmek, 2025’te kabul edilemez. TypeScript strict mode + runtime validation kombinasyonu üç kritik avantaj sunar:

Erken hata tespiti: Geleneksel JavaScript’te hata ancak kullanıcı o kod yoluna girdiğinde ortaya çıkar. Strict mode, editörde kod yazarken tip hatalarını gösterir. Bir API yanıtının user.email yerine user.mail döndüğü senaryoda, TypeScript derleme aşamasında uyarır, Zod ise runtime’da invalid response’u reject eder — kullanıcıya ulaşmadan.

Refactoring güvenliği: 50+ component’li bir proje düşünün. Bir data model’in field adı değiştiğinde, strict mode tüm etkilenen satırları işaretler. Manuel ‘find-replace’ yerine compiler sizi yönlendirir. Gonet portföyünde 200+ sayfa, 30+ API endpoint’li bir e-ticaret projesinde kategori şemasını değiştirdiğimizde, 4 saat yerine 20 dakikada refactor tamamlandı.

Dokümantasyon olarak kod: Tipler canlı dokümantasyondur. ProductCard component’ine bakan developer, kabul edilen prop’ları, zorunlu/opsiyonel alanları, enum değerlerini tip tanımlarından okur. Confluence’da güncellenmeyi unutulan doküman yerine, kod her zaman doğru kaynaktır.

Zod ekosistemindeki kritik rol: API contract’ı zod.object({...}) ile tanımlanınca, aynı şemadan hem TypeScript interface (z.infer<typeof schema>) hem OpenAPI spec hem form validation kuralları türetilebilir. Tek kaynak, üç kullanım — DRY (Don’t Repeat Yourself) prensibinin zirvesi.

Gonet yaklaşımı

Gonet’te TypeScript strict mode standart, Zod ise tüm API ve form katmanlarında zorunludur. Yaklaşımımız üç katmandan oluşur:

1. Schema-first API contracts: Her API endpoint’i için Zod schema yazarız. Örnek Next.js API route:

import { z } from 'zod';

const ProductSchema = z.object({
  id: z.string().uuid(),
  name: z.string().min(1),
  price: z.number().positive(),
  tags: z.array(z.string()).optional()
});

export async function POST(req: Request) {
  const body = await req.json();
  const validated = ProductSchema.parse(body); // Runtime'da tip garanti
  // validated değişkeni artık type-safe
}

Bu yaklaşım hem backend hem frontend’de aynı şemayı kullanır (monorepo’da paylaşılan @repo/schemas paketi). API değiştiğinde, tüm tüketen kodlar derleme hatası verir.

2. Discriminated unions: Form state, async data gibi karmaşık durumlar için discriminated union pattern’i uygularız:

type AsyncData<T> =
  | { status: 'idle' }
  | { status: 'loading' }
  | { status: 'success'; data: T }
  | { status: 'error'; error: string };

React component’lerinde if (state.status === 'success') kontrolü yaptığınızda, TypeScript otomatik olarak state.data’nın mevcut olduğunu bilir. Runtime undefined hatası imkansız hale gelir.

3. Build-time type checks: CI/CD pipeline’da tsc --noEmit komutu zorunlu adımdır. Tip hatası olan kod asla production’a ulaşmaz. GitHub Actions workflow örneği:

- name: Type check
  run: pnpm tsc --noEmit
- name: Validate schemas
  run: pnpm test:schemas # Zod schema'ların kendi test suite'i

Gonet müşterilerinden biri için geliştirdiğimiz headless CMS entegrasyonunda, 40+ content type Zod schema’yla tanımlandı. Content editör yanlış formatta veri girdiğinde, kaydetme öncesi validation UI’da gösterildi — API’ye invalid request asla ulaşmadı. Sonuç: 6 ay içinde production’da sıfır tip hatası.

Hangi durumlarda kritik avantaj?

İlgili yetkinlikler

TypeScript strict mode, modern web stack’inin omurgasıdır ve şu yetkinliklerle sinerji yaratır:

• Next.js App Router: Server Component’lerde end-to-end type safety, özellikle async data fetching’de kritik.
• Headless CMS Entegrasyonu: Content type’ları Zod schema’yla model edilir, GraphQL/REST response’ları runtime validate edilir.
• React Server Components: Server-client boundary’de tip güvenliği, serialization hatalarını önler.
• API Tasarımı (RESTful/GraphQL): Zod schema’lar OpenAPI spec’e dönüştürülür, API dokümantasyonu otomatik güncellenir.

Gonet ile çalışmak

Gonet’in 220+ marka portföyünde TypeScript strict mode, bakım maliyetini ortalama %35 düşürdü. Zod entegrasyonuyla runtime hata oranı %60 azaldı. Ekibimiz, legacy JavaScript kodunuzu kademe kademe TypeScript’e migrate edebilir veya greenfield projenizi ilk satırdan type-safe inşa edebilir. Type safety sadece teknik tercih değil, uzun vadeli yatırım güvencesidir. İletişime geçin, projeniz için type-safe stack stratejisi oluşturalım.