Tek Bir TypeScript Yapılandırmasını Üç Uygulama Arasında Paylaşmak

// packages/typescript-config/base.json
{
  "compilerOptions": {
    "target": "ES2022",
    "lib": ["ES2022"],
    "module": "ESNext",
    "moduleResolution": "Bundler",
    "strict": true,
    "skipLibCheck": true,
    "esModuleInterop": true,
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noUncheckedIndexedAccess": true,
    "forceConsistentCasingInFileNames": true
  }
}

Her uygulamanın (apps/web, apps/api, apps/admin) ve her paketin (packages/schemas, packages/api-hooks) kendi tsconfig.json'ı bu dosyayı extends ediyor ve sadece kendine özgü kısımları (jsx, outDir, module override'ları) üstüne ekliyor.

noUncheckedIndexedAccess — tek satırlık bir karar, her yerde geçerli

Bu ayar, arr[i] gibi index erişimlerinin dönüş tipine otomatik olarak | undefined ekliyor — TypeScript'in varsayılan davranışının aksine. Bu, "dizi sınırlarının dışına çıkma" gibi hataları derleme zamanında yakalıyor. Tek bir yerde açılıp üç uygulamaya da miras kalması, her tsconfig.json'da ayrı ayrı hatırlanması gereken bir ayar olmaktan çıkarıyor — biri unutulursa o uygulama sessizce daha gevşek bir tip güvenliğiyle çalışırdı.

Neden her paket yine de kendi tsconfig.json'ını tutuyor

Paylaşılan taban, her projenin aynı olması gereken kısmını (strict mod, hedef JS sürümü, temel derleyici davranışı) kapsıyor — ama outDir, jsx (React projelerinde react-jsx, API'de yok), module/moduleResolution (CJS/ESM ayrımı, bkz. dual-build şeması) her paketin kendi ihtiyacına özel. extends + override deseni, "ortak olanı bir kere yaz, farklı olanı yerelde tut" ilkesini TypeScript yapılandırmasına da uyguluyor — tıpkı Zod şemalarının paylaşılıp, doğrulamanın her uygulamada kendi bağlamında çalışması gibi.

Bir ayarı değiştirmenin maliyeti

strict modun bir alt bayrağını (örneğin noImplicitAny) tüm projede değiştirmek istersen, tek bir dosyada bir satır değişiyor — altı ayrı tsconfig.json'ı tek tek güncellemek yerine.