TypeScript 7 ölçülebilir biçimde hızlı, ve aynı ölçüde eksik: 7.0 bir programatik API ile gelmiyor.
TypeScript derleyicisi Go ile yeniden yazıldı ve kararlı sürüm 8 Temmuz 2026 tarihinde yayımlandı. Başlıklardaki iddia on kat hızlanma; duyurunun kendisi daha ihtiyatlı konuşuyor ve tam derlemeler için 8 ile 12 kat arasını veriyor. Ama bu yazının konusu hız değil, hızın yanında neyin eksik geldiği. TypeScript 7.0 bir programatik API ile gelmiyor, ve o eksik parça tam olarak bir projenin kapılarının üstünde durduğu yer.
Sayılar gerçek, ve nerede ölçüldükleri önemli
Duyurunun tablosu beş gerçek depo üzerinde alınmış ve TypeScript 6 ile TypeScript 7’yi yan yana koyuyor.
vscode: 125,7 saniyeden 10,6 saniyeye, 11,9 kat.sentry: 139,8 saniyeden 15,7 saniyeye, 8,9 kat.bluesky: 24,3 saniyeden 2,8 saniyeye, 8,7 kat.playwright: 12,8 saniyeden 1,47 saniyeye, 8,7 kat.tldraw: 11,2 saniyeden 1,46 saniyeye, 7,7 kat.
Bunlar tam derleme sayıları, yani sürekli entegrasyonun ölçtüğü şey. Günlük çalışmada daha çok anlam taşıyan ikinci bir sayı var: hata taşıyan bir dosyayı editörde açmak eskiden yaklaşık 17,5 saniye sürüyordu, TypeScript 7 ile 1,3 saniyenin altında. Bağımsız bir habercilik özeti bellek kullanımının yaklaşık yüzde 18 düştüğünü ve bir ekibin sürekli entegrasyon adımının 7,5 dakikadan 1,25 dakikaya indiğini de aktarıyor.
Eksik olan bir API, ve bedelini kimin ödediği belli
While TypeScript 7.0 is here, it does not ship with an API. We expect TypeScript 7.1 to ship with a new (and different) API, but until then we have made it a priority to ensure TypeScript can be run side-by-side with TypeScript 6.0 for utilities that still need some programmatic access to the compiler (such as typescript-eslint).
Cümle duyurunun kendisinden. Pratikte anlamı şu: derleyiciyi programatik olarak çağıran her araç TypeScript 7 üzerinde koşamıyor. Duyurunun adıyla andığı iki araç typescript-eslint ve Volar; ayrıca Vue, Svelte, Astro, MDX ve Angular’ın şablon tip denetimi, çünkü onlar da derleyiciyi gömüyor. Duyuruda geçmiyorlar ama ts-jest ve ts-morph gibi derleyici API’sine dayanan her araç aynı sınıfta duruyor. Sürüm adayı duyurusu bunu daha da açık söylüyordu: kararlı bir programatik API en iyi ihtimalle birkaç ay sonra gelecek.
Somut hâli bir destek kaydında görülebilir. Duyurunun yapıldığı gün açılan kayıtta bir geliştirici bir Vite artı React projesini yükseltmeyi deniyor: npm ci, eş bağımlılık aralığı TypeScript’i 6.1.0’ın altında tuttuğu için düşüyor; kurulum zorlandığında ESLint çalışırken çöküyor. Kayıt planlanmadı notuyla kapatıldı. Bu bir hata raporu değil, bir sınır işareti.
Bir yeniden yazımın maliyeti nerede toplanır
Bu olayın bir yıl sonra da okunabilir tarafı şu: bir derleyiciyi yeniden yazmanın maliyeti derleyicide değil, ona bağlanan yüzeyde toplanıyor. Taşımanın yürütüldüğü depo bunu açıkça yazıyor: ayrıştırma, tip çözümleme, tip denetimi, JSX, bildirim üretimi, izleme modu, proje referansları ve artımlı derleme bitmiş olarak işaretli. Bitmemiş olan iki şey var, dil servisi devam ediyor ve API hazır değil.
Yani en zor kısım algoritmalar değil, on yılda oluşmuş bir arayüzün karşılığını yeni bir dilde vermek. Bir yeniden yazımın dürüst tanımı da bu: aynı işi daha hızlı yapan bir ikili, artı ekosistemin geri kalanının beklediği bir kuyruk.
Yükseltme değil, göç
İkinci maliyet yapılandırmada. TypeScript 7 bir dizi seçeneği artık sert hata sayıyor: target: es5, downlevelIteration, moduleResolution için node10 ve classic, module için amd, umd, systemjs ve none, ve baseUrl. esModuleInterop ile allowSyntheticDefaultImports da artık false olamıyor. Sürüm adayı duyurusu iki varsayılan değişikliğini de sayıyor: rootDir artık çıkarım yerine ./ varsayılıyor, ve types varsayılanı ["*"] değil [], yani tip paketleri tek tek yazılmak zorunda.
Bu listenin iyi tarafı şu: hiçbirini görmek için yükseltmek gerekmiyor. tsconfig.json dosyasını bugün açıp bu anahtarları aramak, göçün ölçülebilir yarısını yükseltmeden bitirir. Geçiş için bir de uyum paketi var, @typescript/typescript6, eski API’yi ve bir tsc6 ikilisini geri veriyor, böylece iki sürüm yan yana koşabiliyor. Yani bugünkü cevap bekle değil, ikisini birden kur.
İki majör sürüm, bir çeyrek
Takvimin kendisi de bir karar. TypeScript 6.0 23 Mart 2026’da çıktı ve 7.0 aynı yılın 8 Temmuz’unda, yani üç buçuk ay arayla iki majör sürüm. Bunun açıklaması acele değil, göçün ikiye bölünmesi: 6.0 duyurusu kendini 5.9 ile 7.0 arasında bir köprü olarak tanımlıyor ve değişikliklerinin çoğunun 7.0’a hazırlanmak için olduğunu söylüyor.
Bölmenin işe yarar tarafı şu: 7.0’da sert hata olan seçeneklerin çoğu 6.0’da zaten kullanımdan kaldırılmış olarak işaretlenmişti, target: es5 ve moduleResolution: node10 de dahil. Yani 6.0’a çıkıp uyarılarını temizlemiş bir proje için 7.0 yalnız bir derleyici değişimi; çıkmamış bir proje aynı anda hem yapılandırma göçünü hem derleyici değişimini üstleniyor. Sürüm numarasının söylediği şey de bu: bir uyumluluk vaadi değil, göçün hangi aşamasında olduğunuzun işareti.
Pratik sonucu, yükseltmeyi tek bir sıçrama olarak değil iki adım olarak planlamak. İlk adım ekosistem riski taşımıyor, çünkü 6.0 hâlâ eski programatik API’yi veriyor ve typescript-eslint ile birlikte koşuyor. İkinci adımın takvimi ise sizin değil, araçlarınızın takvimi, ve o takvim bugün 7.1’i bekliyor.
Bu depoda ne değişirdi
Bu siteyi ölçmek kolay, çünkü kapısı yazılı: tek bir betik, sekiz adım, cms entegrasyon süiti eklendiğinde dokuz, ve bir turu bu makinede iki dakikanın altında bitiyor. O dokuz adımın ikisi tsc --noEmit, biri lint. Yani TypeScript 7 bu depoda iki adımı hızlandırır ve bir adımı karartır, çünkü her iki uygulamanın lint yapılandırması da typescript-eslint üzerinde duruyor. Bu boyuttaki bir depoda derleyici zaten darboğaz değil; kazanç sürekli entegrasyonda değil editörde, kayıp ise doğrudan bir kapının kendisi.
Karar da buradan çıkıyor, ve genel bir tavsiye değil: derleyiciyi doğrudan koşan bir kapıdan başka bir şeyiniz yoksa yükseltme bugün ucuz. Kapılarınızın arasında tip bilgisine dayanan bir lint kuralı, bir şablon denetimi ya da bir kod dönüştürücü varsa, yükseltmek bugün bir kapıyı kapatmak demek. İkisi arasındaki fark bir tercih değil, envanter sorusu.
Pratik karşılığı üç madde. Birincisi, tsconfig.json içindeki kaldırılmış seçenekleri bugün temizlemek: yükseltmeden bağımsız, geri alınabilir ve ucuz. İkincisi, hangi kapının derleyiciyi programatik olarak çağırdığını yazılı hâle getirmek; bu liste genelde kısa çıkıyor ama yükseltmenin gerçek takvimini o belirliyor. Üçüncüsü, hız kazancını doğru yerde ölçmek: on kat, tam derlemede alınmış bir sayı, ve çoğu ekibin günlük olarak hissettiği şey tam derleme değil editörün cevap süresi.
Etiketler
- TypeScript
- Performance