@sedatdemirAra

tsgo: TypeScript derleyicisinin Go portu

Büyük bir TypeScript projesinde tsc --noEmit komutunu çalıştırıp 40-50 saniye beklemek, geliştirme döngüsünü ciddi şekilde yavaşlatır. Bu bekleme süresi projeye eklenen her bin satır kodla birlikte artar. Anders Hejlsberg, Mart 2025'te TypeScript derleyicisinin Go'ya taşındığını duyurduğunda odak noktası tam olarak buydu: tip denetimi süresini büyük projelerde 10 kata kadar düşürmek.

tsgo nedir, neden Go

tsgo (proje içindeki adıyla @anthropic/tsgo değil, doğrudan tsgo), TypeScript derleyicisinin Go dilinde yeniden yazılmış hali. Resmi repo microsoft/typescript-go altında geliştiriliyor. Bu bir "yeniden tasarım" değil; mevcut TypeScript derleyicisinin davranışlarını birebir koruyarak Go'ya çevrilmiş bir port.

Neden Go? TypeScript ekibi birkaç dili değerlendirmiş. C++ ve Rust bellek yönetimi açısından daha ince kontrol sunuyor, ancak mevcut TypeScript derleyicisinin garbage-collected bir dilde yazılmış olması, port sırasında GC'li bir dile geçişi kolaylaştırıyor. Go'nun goroutine modeli de paralel tip denetimi için uygun bir zemin oluşturuyor. Anders Hejlsberg'in kendi açıklamasına göre, Go'nun basit concurrency modeli ve hızlı derleme süreleri bu kararı şekillendiren iki etken.

Performans rakamları

TypeScript ekibinin paylaştığı benchmark sonuçları belirli projelere ait. Bu rakamlar microsoft/typescript-go reposundaki benchmark klasöründen geliyor:

  • VS Code kaynak kodu (yaklaşık 1.5 milyon satır TypeScript): mevcut tsc ile ~77 saniye, tsgo ile ~7.5 saniye.
  • TypeScript derleyicisinin kendi kaynak kodu: mevcut tsc ile ~10 saniye, tsgo ile ~1 saniye.

Bu rakamlar tsc --noEmit modunda, yani sadece tip denetimi yapılırken alınmış. JavaScript çıktısı üretme (emit) aşaması henüz tam olarak optimize edilmemiş durumda.

Hız farkının kaynağı tek başına "Go, JavaScript'ten hızlı" değil. Birkaç mimari değişiklik var:

  1. Paralel parsing: Dosyalar goroutine'ler aracılığıyla eş zamanlı parse ediliyor.
  2. Daha verimli bellek düzeni: Go struct'ları bellekte ardışık yerleşiyor; JavaScript nesnelerindeki pointer chasing sorunu ortadan kalkıyor.
  3. Tek geçişli binder: Mevcut TypeScript derleyicisinde iki geçiş gerektiren bazı binding işlemleri tek geçişe indirilmiş.
  4. String interning: Aynı string değerleri bellekte tekrar tekrar tutulmak yerine tek bir kopyaya referans veriyor.

Mevcut projede deneme

tsgo henüz preview aşamasında (Temmuz 2025 itibarıyla). npm üzerinden yüklenebilir:

npm install -D @typescript/native-preview

Kurulumdan sonra tsgo komutu kullanılabilir hale gelir:

npx tsgo --noEmit

Mevcut tsconfig.json dosyasını okuyor. Henüz desteklenmeyen bazı derleyici seçenekleri var; bunlarla karşılaşıldığında tsgo bir uyarı veriyor ve o seçeneği atlıyor. Projenin tip denetimi sonuçlarını mevcut tsc ile karşılaştırmak için ikisini arka arkaya çalıştırmak yeterli:

# Mevcut tsc ile
time npx tsc --noEmit

# tsgo ile
time npx tsgo --noEmit

Küçük projelerde (birkaç yüz dosya) fark 2-3x civarında kalabilir. Asıl fark binlerce dosya içeren monorepo'larda ortaya çıkıyor.

Bir uyarı: tsgo henüz --build (project references) modunu tam desteklemiyor. Monorepo'larda project references kullanılıyorsa, tek bir paketin tsconfig.json dosyasını hedefleyerek test etmek daha güvenilir sonuç verir.

VS Code entegrasyonu

Performans kazancının en çok hissedildiği yer editör. VS Code'daki TypeScript dil servisi (tsserver) her tuş vuruşunda tip denetimi, otomatik tamamlama ve hata gösterimi yapıyor. Büyük projelerde bu işlemler saniyeler sürebiliyor, özellikle karmaşık generic tipler içeren dosyalarda.

tsgo'nun dil servisi (tsserverd) Go'da yazılmış bir LSP sunucusu olarak çalışıyor. VS Code için resmi bir extension mevcut:

  1. VS Code Extensions panelinde "TypeScript Native Preview" aratılır.
  2. Extension yüklendikten sonra, komut paletinden (Ctrl+Shift+P) "Select TypeScript version" komutu çalıştırılır.
  3. Listeden "Use tsgo" seçilir.

Bu noktadan sonra editördeki tip hataları, hover bilgileri ve otomatik tamamlama tsgo üzerinden çalışmaya başlar. Deneyimlerime göre büyük dosyalarda hover bilgisi gösterimi belirgin şekilde hızlanıyor; 2-3 saniye geciken tooltip'ler neredeyse anlık oluyor.

Henüz bazı eksikler var. Go to definition bazı edge case'lerde çalışmayabiliyor. Rename symbol desteği kısıtlı. Ama temel geliştirme döngüsü olan "yaz, hatayı gör, düzelt" akışı sorunsuz işliyor.

Desteklenen ve desteklenmeyen özellikler

tsgo, TypeScript 5.8 ile uyumlu bir tip sistemi hedefliyor. Desteklenen özelliklerden bazıları:

  • Conditional types, mapped types, template literal types
  • satisfies operatörü
  • const type parameters
  • Discriminated unions
  • infer anahtar kelimesi

Henüz desteklenmeyen veya kısmen desteklenen özellikler (Temmuz 2025 itibarıyla):

  • --build modu (project references) kısmen çalışıyor
  • Bazı JSDoc tabanlı tip çıkarımları eksik
  • paths alias çözümlemesinde nadir edge case'ler
  • Plugin API'si (ts-patch, ttypescript gibi araçlarla çalışmıyor)

Mevcut araçlarla uyum

tsgo bir tip denetleyicisi ve dil servisi. JavaScript çıktısı üretme (transpilation) işini çoğu projede zaten başka araçlar yapıyor: Vite, esbuild, SWC. Bu araçlar TypeScript sözdizimini siler ve JavaScript çıktısını üretir; tip denetimini zaten tscye bırakır. tsgo bu denkleme doğrudan oturuyor.

Vitest kullanan projelerde test çalıştırma süresi tsgo'dan etkilenmez, çünkü Vitest zaten esbuild/SWC ile transpile yapar. Ama CI pipeline'ında tsc --noEmit adımı varsa, onu tsgo --noEmit ile değiştirmek CI süresini belirgin şekilde kısaltır.

Bir örnek CI yapılandırması (GitHub Actions):

# .github/workflows/typecheck.yml
name: Type Check
on: [push, pull_request]
jobs:
  typecheck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npx tsgo --noEmit

Tip uyumsuzluğu riski

Bir derleyiciyi başka dilde yeniden yazmak, davranış farklarını beraberinde getirebilir. TypeScript ekibi bu riski minimize etmek için mevcut derleyicinin test suite'ini (50.000'den fazla test) tsgo üzerinde çalıştırıyor. Haziran 2025 itibarıyla bu testlerin %99'undan fazlası geçiyor.

Ancak pratikte karşılaşılabilecek bir durum var: floating point aritmetiğinde Go ile JavaScript arasındaki küçük farklar, template literal types içinde sayısal hesaplama yapan nadir tiplerde farklı sonuçlar üretebilir. Bu gerçek projelerde neredeyse hiç karşılaşılmayacak bir senaryo, ama kütüphane yazarlarının bilmesi gereken bir ayrıntı.

Mevcut tsc ile tsgo arasındaki farklılıkları tespit etmek için şu yaklaşım işe yarıyor:

# tsc hatalarını dosyaya yaz
npx tsc --noEmit 2>&1 | sort > tsc-errors.txt

# tsgo hatalarını dosyaya yaz
npx tsgo --noEmit 2>&1 | sort > tsgo-errors.txt

# Farkları karşılaştır
diff tsc-errors.txt tsgo-errors.txt

Bu karşılaştırma, geçiş öncesinde güvenli bir adım.

Büyük projelerde pratik etki

tRPC v11 veya Drizzle ORM gibi ağır tip çıkarımı yapan kütüphaneler kullanan projelerde, editör deneyimi doğrudan tip denetimi hızına bağlı. Bu projelerde bir db.select() çağrısının dönüş tipini hesaplamak yüzlerce milisaniye sürebilir. tsgo'nun bu tür derin tip çıkarımlarında ne kadar hızlandığına dair henüz bağımsız benchmark yok, ama TypeScript ekibinin kendi testlerinde conditional type evaluation süresinin 5-8x düştüğü raporlanmış (microsoft/typescript-go#123 tartışmasındaki veriler).

Zod v4 ile birlikte kullanılan z.infer<typeof schema> tarzı tip çıkarımları da bu hızlanmadan fayda görüyor. Zod'un bundle boyutu optimizasyonuyla birlikte düşünüldüğünde, tip katmanının hem runtime hem de geliştirme zamanında hafiflemesi güzel bir kesişim noktası.

Ne zaman geçmeli

tsgo henüz production-ready olarak etiketlenmedi. TypeScript ekibi resmi olarak "preview" diyor. Benim yaklaşımım şu: CI'da tsgo --noEmit çalıştırmak şu an bile güvenli, çünkü en kötü ihtimalle tscye geri dönülür. Editör entegrasyonunu ise büyük projelerde denemek mantıklı; küçük projelerde mevcut tsserver zaten yeterince hızlı.

tsgo'yu tscnin yerine koymayı düşünmek için iki koşulun sağlanması gerekiyor: --build modunun tam desteklenmesi ve plugin API'sinin en azından temel düzeyde çalışması. Bu iki özellik geldiğinde, geçiş çoğu proje için tek satırlık bir değişiklik olacak.