TypeScript 7.0 Hızlı. Asıl Geçiş İşi tsconfig'inizde

TypeScript ekibi 8 Temmuz'da Go ile yazılmış native port'un ilk kararlı sürümü olan TypeScript 7.0'ı yayınladı. Kurulum hâlâ npm install -D typescript, çalıştırdığınız komut hâlâ tsc. Ama derleyici artık paylaşımlı bellekli çoklu iş parçacığıyla native kod olarak çalışıyor ve ekibe göre tam build'ler genellikle 8 ila 12 kat daha hızlı. İşin kolay kısmı hız. Asıl iş, 6.0'dan devralınan varsayılanlarda ve henüz ortada olmayan programatik API'de.

Gerçekte ne yayınlandı#

Benchmark tablosundan birkaç satır (varsayılan dört type-checker ile çalıştırılmış):

• VS Code kod tabanı: TypeScript 6'da 125.7s, 7'de 10.6s (11.9x).
• Sentry: 139.8s'den 15.7s'ye (8.9x). Playwright: 12.8s'den 1.47s'ye.
• Bellek kullanımı da projeye göre %6 ile %26 arasında düştü.

Language service artık Language Server Protocol üzerine kurulu ve eşzamanlı istekleri karşılamak için birden fazla thread kullanabiliyor. VS Code reposunda hata içeren bir dosyayı açtığınızda ilk hatanın görünmesi yaklaşık 17.5 saniyeden 1.3 saniyenin altına indi. VS Code için bugün ayrı bir TypeScript 7 eklentisi var; ekip, desteğin önümüzdeki haftalarda doğrudan VS Code'un içine geleceğini söylüyor.

Geçişin kendisi varsayılanlar#

TypeScript 7, 6.0'ın yeni varsayılanlarını benimsiyor ve 6.0'da deprecated edilen flag'leri ve yapıları doğrudan hataya çeviriyor. Canınızı yakacak varsayılanlar:

• strict artık true, module esnext, target ise esnext'ten hemen önceki güncel kararlı ECMAScript sürümü.
• stableTypeOrdering true ve kapatılamıyor. noUncheckedSideEffectImports açık.
• types artık varsayılan olarak []. process veya describe gibi global'lerin arkasındaki @types paketlerinin listelenmesi gerekiyor; ["*"] eski davranışı geri getiriyor.
• rootDir artık varsayılan olarak ./. tsconfig.json dosyanız src dışında duruyorsa, aynı çıktı yapısını korumak için rootDir'i ayarlamanız gerekiyor.

İki düzeltme de küçük:

{
  "compilerOptions": {
    "rootDir": "./src",
    "types": ["node", "jest"]
  },
  "include": ["./src"]
}

Artık doğrudan hata verenler şunlar: target: es5, downlevelIteration, moduleResolution node/node10/classic, module amd/umd/systemjs/none ve baseUrl. Ayrıca esModuleInterop veya allowSyntheticDefaultImports değerlerini false yapamıyorsunuz. baseUrl için yazıda paths'in proje köküne göre relative olacak şekilde güncellenebileceği belirtiliyor. Import'lardaki asserts anahtar kelimesinin de with olması gerekiyor.

Pre-commit hook'larını bozma ihtimali yüksek bir değişiklik daha var: mevcut dizinde bir tsconfig.json varsa, --ignoreConfig vermediğiniz sürece tsc artık dosya yolu kabul etmiyor. Stage'lenmiş dosya yollarını tsc'ye geçen script'lere bir göz atmak gerekiyor.

7.1'e kadar API yok#

TypeScript 7.0 programatik bir API olmadan geliyor. Ekip, 7.1 ile yeni ve farklı bir API gelmesini bekliyor. O zamana kadar:

• typescript-eslint ve derleyiciye programatik erişim gerektiren diğer araçlar hâlâ 6.0'a bağımlı.
• Vue, MDX, Astro ve Svelte projelerinin şimdilik 6.0'da kalması gerekecek, çünkü Volar gibi araçlar TypeScript'i kendi derleyicilerine ve language service'lerine gömüyor.
• Angular projeleri komut satırında proje genelinde hızlı hata kontrolü için 7'nin tsc'sini kullanıp editör desteği için 6.0'ı tutabilir.

Köprü görevini yeni bir paket görüyor: @typescript/typescript6. Bu paket bir tsc6 binary'si sağlıyor ve 6.0 API'sini yeniden export ediyor. npm alias'larıyla ikisini birlikte tutabilirsiniz:

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}

typescript'i peer dependency üzerinden import eden araçlar 6.0 almaya devam ediyor, npx tsc ise 7.0'ı çalıştırıyor. Geçmeden önce typescript'i kütüphane olarak import eden her şeyi grep'leyin: lint config'i, bundler loader'ları, codegen script'leri. O liste sizin 7.1 bekleme salonunuz.

CI'da baştan karar verilmesi gereken ayarlar#

TypeScript 7, iki deneysel paralellik flag'i ve bir de tek thread'e geçiren bir anahtar ekliyor.

• --checkers type-checking worker sayısını belirliyor. Varsayılan 4. Yazı, CI runner'ları gibi daha az çekirdekli ve daha az bellekli makinelerde bu değerin düşürülmesini öneriyor. Ayrıca farklı bir checker sayısının nadir durumlarda sıraya bağlı sonuçlar ortaya çıkarabileceği konusunda uyarıyor; bu yüzden tüm ortamlarda tek bir değere sabitlemek mantıklı.
• --builders, --build altında project reference build'lerini paralel çalıştırıyor. --checkers ile çarpılıyor: 4 builder ve 4 checker, aynı anda 16'ya kadar type-checker demek.
• --singleThreaded paralelliği tamamen kapatıyor.

Bu, birden fazla process aynı makineyi paylaştığında daha da önemli hale geliyor. Çoğu gün birden fazla coding agent'ı paralel çalıştırıyorum ve type-check, onların patch'leri için doğal bir kapı. Saniyeler süren bir kapı, onu ne sıklıkla çalıştırmayı göze alabileceğinizi değiştiriyor. Ama aynı makinede, her biri varsayılan olarak dört checker kullanan birkaç tsc çalışması bellekte hızla birikiyor. Böyle bir kurulumda varsayılana güvenmek yerine --checkers'ı açıkça ayarlardım.

Ben ne yapıyorum#

TypeScript işlerimin çoğu React, Next.js, Expo ile React Native ve Fastify üzerinde Node servisleri. Benim için asıl soru, hangi lint ve build araçlarının derleyiciyi import ettiği. Planım sırasıyla şöyle:

1. Her projenin 6.0'da stableTypeOrdering açıkken ve ignoreDeprecations olmadan temiz derlenmesini sağlamak. Ekip, bu koşullarda geçen neredeyse her kodun 7.0'da da birebir aynı şekilde derlenmesi gerektiğini söylüyor.
2. Henüz 6.0'dayken types ve rootDir'i açıkça belirtmek ve baseUrl'i şimdiden değiştirmek; böylece diff review edilebilir kalır.
3. CI type-check job'ını sabitlenmiş bir --checkers değeriyle 7'nin tsc --noEmit'ine taşımak, lint ve derleyiciyi gömen her şey için 6.0'ı alias'la tutmak.
4. API'ye ihtiyaç duyan toolchain'lere dokunmadan önce 7.1'i beklemek.

Sadece type-check job'ı bile bu emeğe değer. Yeter ki bunu basit bir sürüm yükseltmesi gibi görmeyin.