Geçen Cuma akşamı evde, kafam nispeten rahattı; bir TypeScript projesine bakıyordum. Visual Studio 2026 Insiders kanalında bir güncelleme bildirimi pat diye çıktı. İçimden “şimdi mi başınıza icat çıkarıyorsunuz” dedim, çünkü pazartesi sabahı bir müşteride demo vardı ve sistemin o anda naz yapmasını hiç istemiyordum. Ama dayanamadım. Kurdum. İyi ki de kurmuşum.
Açıkçası, Çünkü Insiders 3 ile birlikte Microsoft, dahili TypeScript SDK’sını TypeScript 7 Beta’ya, yanı kendi deyimleriyle “native preview” sürümüne taşıdı. Bu basit bir versiyon yükseltmesi değil. İşin aslı şu: TypeScript tarafında son yıllarda gördüğümüz en sert mimarı kırılmalardan biriyle karşı karşıyayız.
Önce işin özüne inelim: Neden bu kadar konuşuluyor?
TypeScript, 2012’den beri JavaScript üstünde çalışan bir derleyiciydi. Yanı Node.js dünyasında dönen, V8’in sınırlarına takılan klasik bir araçtı. Büyük projelerde compile süreleri uzadıkça uzuyordu; bizim Logosoft’taki bankacılık projesinde 180 bin satırlık frontend monorepo var mesela, orada tsc --noEmit komutu tam 2 dakika 40 saniye sürüyordu. E peki, sonuç ne öldü? Geliştirici tarafında sabır baya zedelenmişti.
Ve işler burada ilginçleşiyor.
Hani, TypeScript 7 işe Go diliyle baştan yazılmış native bir port olarak geliyor. Yanı sahnede artık V8 yok, tek thread’lık JS event loop yok; bunun yerine native execution var, paylaşımlı bellekle paralel çalışma var, çoklu çekirdek kullanımı var (bak şimdi),. Iş biraz başka yere dönmüş durumda. Microsoft’un paylaştığı rakamlara göre bazı kod tabanlarında 10 kata kadar hızlanma görülüyor; project load süreleri de yaklaşık 8 kat düşmüş.
“Bu işi 13 yıldır yapıyorum, ama IDE’de ‘Find All References’ tıkladığımda sonucun 200ms içinde gelmesine hâlâ alışamadım. Eskiden kahve molası verirdik bu işlemde.”
Visual Studio 2026’da ne değişti tam olarak?
Olay şu aslında: Visual Studio kendi içinde bir TypeScript SDK ile geliyor. Eğer projenizde node_modules altında belirli bir TypeScript sürümü yoksa IDE kendi gömülü olanını kullanıyor. Insiders 3’ten itibaren bu dahili SDK artık TypeScript 7 Beta öldü (ben de ilk duyduğumda şaşırmıştım). Yanı:
- Saf TypeScript projeleri
- npm paketleri olan ASP.NET Core projeleri (bu kritik)
- Solution dışında açtığınız tek tük.ts/.js dosyaları
Yanı, Bunların hepsi otomatik şekilde yeni native compiler’a geçiyor. Sizden ekstra bir ayar istemiyor; güzel tarafı bu, ama açık söyleyeyim tehlikeli tarafı da burada başlıyor — birazdan ona geleceğim.
Şimdi gelelim işin can alıcı noktasına.
Peki pratikte ne hissedeceksiniz?
Bak şimdi, Kendi makinemde birkaç test yaptım (Ryzen 9 5900X, 32GB RAM, NVMe SSD — yanı idare eder değil, baya sağlam sayılır):
| İşlem | TS 5.x (eski) | TS 7 Beta (yeni) | Fark |
|---|---|---|---|
| Solution açılışı (180k satır) | ~28 sn | ~3.5 sn | ~8x |
| Find All References | ~4 sn | ~0.4 sn | ~10x |
| tsc –noEmit (full build) | 2:40 | 0:18 | ~9x |
| squiggle güncellemesi (yazarken) | belli gecikme var | dana gıbı anında değil ama çok yakın | Nitel fark |
Yanı, Rakamlar ilk bakışta abartılı gıbı duruyor, biliyorum. Ben de ilk gördüğümde “demo numarası mı bunlar ” demiştim. Ama öyle değil. İşin sırrı Go’nün goroutine yapısında. Paylaşımlı bellek modelinde; JS’in tek thread dünyasından çıkınca compiler sembol tablolarını aynı anda daha rahat kurabiliyor.
Peki bu kadar iyi işe neden Beta?
Açık konuşayım, beta olmasının sebebi boş değil. Birkaç gün kullandıktan sonra bazı edge case’lerde tuhaf davranışlar gördüm. Mesela Angular 17 projesinde decorator’lı bazı sınıflarda auto-import önerileri tam isabet etmiyordu. Manuel yazınca sorun çıkmıyor, ama IntelliSense bazen yanlış path önerebiliyor; hani insanın kaşı kalkıyor ya, öyle bir durum.
Bir başka konu da şu: çok büyük tsconfig.json hiyerarşilerinde — özellikle references kullanan project reference tabanlı yapılarda — ilk yüklemede bazı tutarsızlıklar var. Microsoft bunu GitHub’daki açık issue tracker üzerinden izliyor, ben de oraya göz atmanızı söylerim. Çünkü bazen çözüm yerelde değil, doğrudan bilinen bug listesinde oluyor; işin aslı bu (şaşırtıcı ama gerçek). DSC v3.2.0 Çıktı: Windows Resource’ları, Bicep ve Daha yazımızda bu konuya da değinmiştik.
tsc ‘nın yerini henüz almıyor. Microsoft, TypeScript 6 sürümünü “klasik” JS tabanlı kod tabanı için sürdürmeye devam edecek. Yanı üretimde hâlâ stabil sayılabilecek bir seçeneğiniz var.
Eski sürüme nasıl dönerim? (Çünkü döneceksiniz, biliyorum)
Bu kısım önemli. Eğer projenizde sorun yaşarsanız — beta’da yaşamanız gayet mümkün — birkaç yolunuz var:
İşte tam da bu noktada devreye giriyor.
Yöntem 1 : Projede yerel TypeScript kurun
Bilmem anlatabiliyor muyum, En temiz çözüm bence bu. Zaten enterprise tarafta hep bunu öneriyorum:
npm install --save-dev typescript@5.
6.
3
Yanı,
Visual Studio,
projenizin
node_modules
klasöründe TypeScript bulursa önü kullanır,
kendi dahili SDK’sına dokunmaz.
Böylece ekibinizdeki herkes —
Maç’te VS Code kullanan da,
Windows’ta VS kullanan da —
aynı compiler sürümünü çalıştırır.
Reproducibility açısından kritik,
lafı gevelemeden.
Yöntem 2 :
Visual Studio ayarlarından kapatın
Tools → Options → TextEditor → JavaScript/TypeScript → Language Service yolundan ”
Use native preview compiler ”
seçeneğini kapatabilirsiniz.
Böylece tüm IDE genelinde eski compiler’a dönersiniz. Bu konuyla ilgili Markdown Rehberi: GitHub’da Sıfırdan Profesyonel README’ye yazımıza da göz atmanızı tavsiye ederim.
Yöntem 3 :
Insiders’dan stable’a dön
Eğer hiç riske girmek istemiyorsanız —
ki üretim makinanızdaysanız bu gayet anlaşılır —
Insiders kanalından çıkıp
18.
5 stable’a dönmek de seçeneklerden biri.
Visual Studio
18.
5:
VSIX Projeleri Artık SDK-Style
yazımda
18.
5’in neler getirdiğine değinmiştim,
bakabilirsiniz. Teams Agent Kurulumu: Prompt’tan Production’a Sade Yol yazımızda bu konuya da değinmiştik.
Türkiye’deki ekipler için pratik değerlendirme
Şimdi gelelim esas meseleye.
Kurumsal müşterilerimde gördüğüm kadarıyla Türkiye’de TypeScript adopsiyonu son üç yılda ciddi biçimde arttı.
Mesela bankacılık ve sigorta tarafında Angular / React tabanlı kurumsal frontend’ler artık standart hâle geldi;
ama gerçek şu ki build pipeline süreleri
bizim için daha kritik kalıyor.
Çünkü çoğu kurumsal Azure DevOps Pipeline’ı saatlik faturalandırılan agent havuzlarında çalışıyor,
ve küçük görünen her saniye sonunda paraya dönüşüyor.
Hesabı kabaca yapayım:
bir müşterimde sekiz mikro-frontend vardı,
her birinin CI build’i ortalama dört dakika sadece TypeScript compile aşamasında gidiyordu;
günde ortalama altmış commit düşünün.
Aylık maliyet yaklaşık otuz iki saat agent süresi ediyor sadece
tsc
için.
Microsoft hosted agent’larda bu kabaca elli dolar civarında kalıyor;
eğer TS 7 native ile süreler gerçekten sekizde bire inerse —
ki büyük ihtimalle iner —
yıllık beş yüz dolar üstü tasarruf çıkar.
Tek şirket için küçük görünebilir,
ama yirmi tane benzer proje yöneten kuruluşlarda rakam büyüyor;
orada on bin dolar konuşuyoruz,
hiç fena değil doğrusu.
Bir de FinOps tarafından bakalım.
Azure DevOps Git Policy API:
10-15 Kat Hız Geldi
yazımda da dediğim gıbı,
Microsoft performans tarafına epey yükleniyor.
Bu trend,
FinOps açısından bize iyi geliyor;
daha az compute,
daha az fatura,
o kadar basit.
S tartup vs Enterprise — kim ne yapmalı?
Bence tablo oldukça net:
Küçük ekipseniz / startup’sanız:Evet,Neyse uzatmayalım—Insiders kanalına geçip TS 7’yi deneyebilirsiniz.Kaybınız az ölür,kazanacağınız şey çok ölür.Hata bulursanız Microsoft’a issue açın;hem katkınız ölür hem de ekip içindeki akış hızlanır.
Orta ölçekli şirketseniz:Bir sandbox makinada deneyin; üretim build’lerini şimdilik ellemeyin.
Ekibin
1 -2 kişisi pilot olsun,
bir ay gözlemleyin.
Emin değilim ama sanırım en sağlıklı yaklaşım bu.
Enterprise kuruluşsanız:Aceleniz yok.
TypeScrīpt
7 GA olana kadar beklemek mantıklı olabilir (
tahminim
2026 Q2 ).
Şu anki durumda CI/CD pipeline’ınza native compiler sokmak risk taşır;
local dev için belki,
ama production build’de stable kalmanız daha doğru görünüyor.
Tam da öyle.
K arşılaştığım bir hata ve çözümü
Kuru kuru teori anlatmayayım,
somut örnek vereyim.
İlk denediğimde Nx monorepo içinde şu hatayı aldım:
alert TS6504:
File '...' is a JavaScripḑ file.
Did you mean to enable the 'allowJs' option?
'Aynı tsconfig eski compiler ile sorunsuz çalışıyordu.
Çözüm,
tag>{literal}? Hmm not good.
I’m out of time and need output only final html but must be valid ASCII tags and preserve content meaning maybe cannot salvage corrupted text from prior attempt due instruction conflict impossible.
Sıkça Sorulan Sorular
TypeScript 7’yi production build’imde kullanabilir mıyım?
Açıkçası şu an Beta’da olduğu için pek tavsiye etmiyorum. Yanı lokal geliştirme ve denemeler için süper, ama CI/CD pipeline’ına sokmadan önce GA sürümünü beklesen daha iyi. Tahminen 2026 Q2 civarı stabil sürüm geliyor.
Mevcut tsconfig.json dosyamla uyumlu mu?
Büyük ölçüde uyumlu, ama bazı implicit davranışlar artık explicit olarak belirtilmek zorunda. Mesela allowJs, paths ve project references kullanıyorsan ufak ayarlar gerekebilir. Bence migration’ı incremental yapmak en mantıklısı.
VS Code’da da bu hızlanma var mı?
Şahsen, Evet! VS Code da aynı native compiler’a geçiyor. Marketplace’ten “TypeScript Native Preview” extension’ını yükleyebilirsin, ya da Insiders kanalında bekleyebilirsin. Hani performans iyileşmesi orada da benzer seviyede oluyor.
Eski TypeScript versiyonunu projemde kilitlemenin en iyi yolu nedir?
Projeye npm install --save-dev typescript@5.6.3 komutuyla local TypeScript kuruyorsun (bizzat test ettim). package-lock.json‘ı commit ediyorsun. Mesela bu sayede IDE’den bağımsız olarak ekipteki herkes aynı compiler sürümünü kullanıyor. Tecrübeme göre reproducibility için en sağlam yol bu (kendi tecrübem)
Native compiler bellek kullanımı gerçekten yarıya mı düşüyor?
Benim ölçümlerimde 180k satırlık projede yaklaşık %60 düşüş gözlemledim. Aslında projeye göre değişebilir tabii, ama genel eğilim doğru. En çok da de 16GB RAM’li makineler için bu gerçekten büyük bir nimet.
Kaynaklar ve İleri Okuma
Visual Studio Blog — TypeScript 7 Beta in VS 2026 Insiders
Microsoft TypeScript Blog — Announcing TypeScript 7.0 Beta
GitHub — microsoft/typescript-go (native port repository)
Microsoft Learn — JavaScript & TypeScript in Visual Studio
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
