TypeScript 7 Gerçekten 10 Kat Hızlı mı? Next.js 16’da Gerçek Geçiş Testi

Test ve inceleme tarihi: 24 Temmuz 2026. TypeScript 7, “10 kat daha hızlı” iddiasıyla yayımlandı. Ben de bu iddiayı yalnızca duyuru metninden aktarmak yerine, üretimde kullandığım Next.js 16 projesinde TypeScript 5.9.3 ile 7.0.2’yi aynı komutla karşılaştırdım.

Sonuç belirgin: tsc --noEmit kontrolünün medyanı 4,79 saniyeden 0,45 saniyeye indi. Bu projede yaklaşık 10,6 kat hızlanma ve geçen sürede yaklaşık %90,6 azalma demek. Fakat yükseltmenin ikinci yarısı sayıdan daha önemliydi: TypeScript 7’ye tek paketle doğrudan geçiş çalışmadı. Programatik compiler API kaldırıldığı için test araçları kırıldı ve TypeScript 6 uyumluluk paketini 7 ile yan yana çalıştırmak gerekti.

Kısa cevap

Soru	Bu projede gördüğüm sonuç
TypeScript 7 gerçekten daha hızlı mı?	Evet. Beş koşuluk CLI typecheck medyanı 4,79 saniyeden 0,45 saniyeye düştü: yaklaşık 10,6 kat.
Bu, Next.js production build’inin 10,6 kat hızlandığı anlamına mı geliyor?	Hayır. Ölçüm yalnızca tsc --noEmit --incremental false komutuna ait.
npm install -D typescript ile doğrudan geçiş oldu mu?	Hayır. Projedeki bazı testler ve araçlar eski compiler API’ye ihtiyaç duyduğu için tek paketli kurulum kırıldı.
Çalışan çözüm neydi?	CLI için TypeScript 7.0.2, API bağımlıları için TypeScript 6 uyumluluk paketini yan yana kurmak.
Proje doğrulamaları geçti mi?	Evet: lint, 49 test, production build ve dört temel rota için yerel smoke test geçti.

TypeScript neden Go ile yeniden geliştirildi?

TypeScript 6 ve öncesindeki compiler, TypeScript ile yazılıp JavaScript olarak çalışıyordu. TypeScript 7 ise Go tabanlı yeni bir kod tabanına geçti. Ekip bunu davranışı baştan tasarlayan serbest bir rewrite olarak değil, mevcut compiler’ın yapı ve mantığını mümkün olduğunca koruyan sadık bir port olarak anlatıyor.

Resmî TypeScript 7 duyurusu, kazancı üç ana değişime bağlıyor: native kod, paylaşımlı bellek kullanan çoklu iş parçacığı ve yeni optimizasyonlar. Microsoft’un kendi tam build ölçümlerinde hızlanma 7,7 ile 11,9 kat arasında değişiyor. VS Code 125,7 saniyeden 10,6 saniyeye, Sentry 139,8 saniyeden 15,7 saniyeye ve Playwright 12,8 saniyeden 1,47 saniyeye inmiş.

Bu sayılar güçlü, fakat garanti değil. Projenin büyüklüğü, type graph yapısı, işlemci çekirdeği, disk, CI limiti ve kullanılan compiler seçenekleri sonucu değiştirir. TypeScript 7 varsayılan olarak dört checker worker kullanıyor; daha fazla worker bazı büyük projeleri hızlandırabilirken düşük bellekli CI makinelerinde ters etki yaratabilir.

Test ettiğim proje ve ortam

Karşılaştırmayı bu sitenin açık kaynak kod tabanında yaptım. Başlangıç noktası Next.js 16.2.10 ve TypeScript 5.9.3’tü. Proje React 19 kullanıyor; uygulama, API rotaları, yönetim paneli ve test dosyaları birlikte typecheck ediliyor.

Parça	Değer
Makine	Apple M4 Max, 16 çekirdek, 48 GB bellek
İşletim sistemi	macOS 26.2
Node.js / npm	Node.js 24.18.0 / npm 11.12.1
Framework	Next.js 16.2.10, Webpack production build yolu
Karşılaştırılan compiler’lar	TypeScript 5.9.3 ve TypeScript 7.0.2
Komut	tsc --noEmit --incremental false

--incremental false seçimi bilinçliydi. Projenin normal ayarında incremental kontrol açık ve tsconfig.tsbuildinfo üretiyor. İki compiler’ı kendi eski cache dosyalarının etkisi olmadan karşılaştırmak için benchmark sırasında incremental durumu kapattım. Her koşuyu aynı çalışma ağacında, aynı bağımlılıklarla ve aynı Node 24.18.0 binary’siyle arka arkaya çalıştırdım. TypeScript 5.9.3’ü geçici ve izole bir dizine kurduğum için benchmark, geçiş yapılmış projenin bağımlılıklarını yeniden yazmadı.

repeat 5 {
  /usr/bin/time -p ./node_modules/.bin/tsc \
    --noEmit \
    --incremental false
}

Sonuç: yaklaşık 10,6 kat daha hızlı typecheck

Her compiler’ı tam beş kez çalıştırdım. TypeScript 5.9.3 sırasıyla 5,41; 4,73; 4,77; 4,82 ve 4,79 saniyede tamamlandı. TypeScript 7.0.2 ise 0,51; 0,45; 0,44; 0,42 ve 0,46 saniye sürdü.

Compiler	Beş koşu	Aralık	Medyan
TypeScript 5.9.3	5,41 / 4,73 / 4,77 / 4,82 / 4,79 sn	4,73–5,41 sn	4,79 sn
TypeScript 7.0.2	0,51 / 0,45 / 0,44 / 0,42 / 0,46 sn	0,42–0,51 sn	0,45 sn

Beş koşunun medyanlarını karşılaştırınca oran yaklaşık 4,79 / 0,45 = 10,6. Geçen sürede azalma ise yaklaşık (4,79 - 0,45) / 4,79 = %90,6.

Yerel 10,6 kat sonucu Microsoft’un tipik 8–12 kat aralığının içinde, fakat ölçümler aynı şeyi karşılaştırmıyor. Microsoft çoğunlukla TypeScript 6 ile 7 arasında büyük codebase’lerin tam build süresini ölçüyor. Benim testim TypeScript 5.9’dan 7’ye, orta boy bir Next.js projesinde, emit ve incremental cache olmadan yapılan project-wide typecheck. Bu nedenle sayıları aynı benchmark tablosunun devamı gibi sunmak doğru olmaz.

Bu benchmark neyi kanıtlamıyor?

• Next.js production build’inin tamamının 10,6 kat hızlandığını kanıtlamıyor.
• Editör autocomplete veya ilk hata gösterme süresini ölçmüyor.
• CI ortamındaki süre ve bellek tüketimini ölçmüyor.
• Her TypeScript projesinin aynı oranı göreceğini söylemiyor.
• TypeScript 7’nin bütün framework araçlarıyla API seviyesinde uyumlu olduğunu göstermiyor.

Gösterdiği şey daha dar ve kullanışlı: bu repository’de, aynı makinede ve aynı ayarlarla çalışan bağımsız TypeScript 7 CLI typecheck’i yaklaşık 10,6 kat hızlandı.

Doğrudan yükseltme neden kırıldı?

İlk denemede TypeScript 5.9.3’ü normal biçimde 7.0.2’ye yükselttim:

npm install --save-dev typescript@^7.0.2
npm run typecheck

Compiler başladı, fakat proje temiz geçmedi. Test dosyalarının bir bölümü kaynak modülleri geçici olarak dönüştürmek için typescript paketini doğrudan içe aktarıyor ve şu API’leri kullanıyordu:

• transpileModule
• ModuleKind
• ScriptTarget

TypeScript 7 paketi programatik JavaScript API’si sunmadığı için bu isimlerin artık bulunmadığını belirten TS2339 hataları geldi. typescript-eslint bağımlılık ağacı da TypeScript 7’yi geçerli peer aralığı dışında işaretledi.

Bu beklenmedik bir gizli hata değil. Resmî duyuru, TypeScript 7.0’ın API ile gelmediğini ve yeni, farklı API’nin 7.1 için planlandığını açıkça söylüyor. Compiler’ı kendi sürecine gömen araçlar bugün hâlâ TypeScript 6 API’sine ihtiyaç duyabiliyor. TypeScript ekibi bu geçiş dönemi için @typescript/typescript6 uyumluluk paketini yayımladı.

Çalışan kurulum: TypeScript 7 ve 6 yan yana

Projede uyguladığım çözüm, TypeScript ekibinin önerdiği npm alias düzeni:

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

Bu yapıdaki görev ayrımı şöyle:

• tsc komutu TypeScript 7.0.2 native compiler’ını çalıştırıyor.
• typescript import eden ESLint, Next.js veya test yardımcıları TypeScript 6 uyumluluk API’sini görüyor.
• tsc6 komutu gerektiğinde eski compiler yolunu ayrıca erişilebilir tutuyor.

Yani proje CLI typecheck için TypeScript 7’ye geçti, fakat ekosistemin API bağımlı parçaları geçiş tamamlanana kadar TypeScript 6 köprüsünü kullanıyor. Bu ayrımı saklamamak önemli. “TypeScript 7 kuruldu” demek doğru; “bütün araç zinciri artık yalnızca TypeScript 7 kullanıyor” demek değil.

Uygulanan değişiklik açık GitHub commit’inde görülebilir.

Geçişten sonra neleri doğruladım?

Hızlı bir compiler tek başına yeterli değil. Yan yana kurulumu tamamladıktan sonra normal proje kapılarını yeniden çalıştırdım:

• Typecheck: TypeScript 7.0.2 ile geçti.
• Lint: bütün repository’de ESLint hatasız tamamlandı.
• Testler: 49 testin tamamı geçti.
• Production build: Next.js 16.2.10 build’i tamamlandı ve 61 statik sayfa üretildi.
• Yerel smoke test: ana sayfa, blog, iletişim ve açık kaynak rotaları HTTP 200 döndürdü; render sırasında page error oluşmadı.

Production build sırasında Next.js’in kendi “Running TypeScript” aşaması 11,1 saniye sürdü. Bu sayı, üstteki 0,45 saniyelik bağımsız CLI ölçümüyle doğrudan karşılaştırılmamalı: Next.js kendi oluşturduğu tipleri, framework entegrasyonunu ve TypeScript 6 uyumluluk API yolunu kullanıyor. Tam da bu yüzden yazının sonucu “Next.js build 10 kat hızlandı” değil, “bağımsız project-wide typecheck 10,6 kat hızlandı”dır.

TypeScript 7’ye geçmeden önce kontrol listesi

1. Önce baseline alın. Aynı commit, makine, Node sürümü ve compiler seçenekleriyle birkaç koşu kaydedin.
2. Incremental cache’i bilinçli yönetin. Soğuk ölçümde --incremental false kullanın veya build info dosyasını kontrollü temizleyin. Günlük kullanım ölçümünde ise normal cache’inizi koruyun.
3. Compiler API kullanan bağımlılıkları arayın. Kodda import ts from "typescript", transpileModule, createProgram veya language-service çağrıları varsa tek paketli geçiş muhtemelen yeterli değildir.
4. TypeScript 6 deprecation’larını düzeltin. TypeScript 7; target: es5, moduleResolution: node10, baseUrl, downlevelIteration ve eski module hedefleri gibi kaldırılan ayarları artık sert hata olarak ele alıyor.
5. rootDir ve types varsayımlarını kontrol edin. TypeScript 7’nin yeni varsayılanları, özellikle global @types paketlerine sessizce güvenen projeleri şaşırtabilir.
6. CLI ve framework typecheck’ini ayrı test edin. tsc --noEmit geçerken framework build’i farklı bir API yolu kullanabilir.
7. Lint, test, build ve çalışma zamanı smoke test’i yapın. Yalnızca compiler’ın çıkış koduna bakmayın.

Bu projedeki tsconfig.json geçiş açısından avantajlıydı: strict zaten açıktı, module değeri esnext, moduleResolution değeri bundler ve paths girdileri proje köküne göre tanımlıydı. Kaldırılan baseUrl veya eski Node resolution modu kullanılmıyordu.

Kim doğrudan geçmemeli?

TypeScript ekibi; Vue, MDX, Astro, Svelte ve Angular gibi TypeScript’i kendi compiler veya language-service süreçlerine gömen iş akışlarının henüz TypeScript 7’den tam yararlanamayabileceğini belirtiyor. Sorun TypeScript sözdizimi değil, kararlı programatik API’nin 7.0’da bulunmaması.

Aşağıdaki durumlarda önce yan yana kurulum veya bekleme daha güvenli:

• Framework veya template compiler doğrudan TypeScript API’sini kullanıyorsa.
• Özel transformer, AST aracı veya ts.createProgram tabanlı kodunuz varsa.
• ESLint ve editor plugin’leriniz TypeScript 7 peer aralığını henüz kabul etmiyorsa.
• CI ortamınız sınırlı çekirdek veya belleğe sahipse ve çoklu checker davranışını ölçmediyseniz.
• TypeScript 6’da kaldırılacak seçenekleri hâlâ ignoreDeprecations ile erteliyorsanız.

Son karar: geçmeye değer mi?

Bu proje için evet. tsc --noEmit geliştirme ve CI akışında sık çalıştırılan bir kapı; 6 saniyelik kontrolün bir saniyenin altına inmesi gerçek bir geri bildirim kazanımı. Üstelik lint, 49 test, production build ve yerel rotalar geçişten sonra çalışmaya devam etti.

Ama doğru geçiş “version numarasını değiştir ve bitir” olmadı. TypeScript 7’nin en büyük avantajı olan native CLI bugün kullanılabilirken, API bağımlı ekosistem için TypeScript 6 köprüsü hâlâ gerekli. TypeScript 7.1 yeni API’yi getirdiğinde bu kurulum yeniden değerlendirilmeli.

Bu deneyden çıkan en dürüst cümle şu: TypeScript 7, bu Next.js 16 projesindeki bağımsız typecheck’i yaklaşık 10,6 kat hızlandırdı; ancak doğrudan tek paketli geçiş çalışmadı.

Birincil kaynaklar ve tekrar üretilebilirlik

• TypeScript ekibi: Announcing TypeScript 7.0 — performans, paralellik, yan yana kurulum ve API sınırları
• TypeScript ekibi: Announcing TypeScript 6.0 — 7.0 öncesi deprecation ve geçiş değişiklikleri
• TypeScript 7 değişiklik günlüğü — TypeScript 6 ile bilinçli davranış farkları
• TypeScript 7’nin Go tabanlı açık kaynak kod deposu
• Bu yazıda anlatılan TypeScript 7 geçiş commit’i

Benchmark tek bir makine ve repository üzerinde yapılmıştır. Süreler wall-clock değerleridir; bellek kullanımı, editör language server gecikmesi ve CI performansı ölçülmemiştir. Sonuçlar 24 Temmuz 2026 tarihinde TypeScript 5.9.3 ve 7.0.2 ile kaydedilmiştir.