Sun Aug 09 2026
Merhaba! 👋
TypeScript 7’nin duyurulduğunu duydun mu? Ben de ilk duyduğumda “Bu ne değişiyor?” diye merak ettim. Bu yazıda, yeni sürümün getirdiği en kritik değişiklikleri ve neden bu kadar önemli olduğunu kısa ve öz anlatacağım.
Ne öğreneceksin?
Hazırsan, beraber TypeScript 7’nin neden bu kadar büyük bir adım olduğunu keşfedelim! 🚀
Hazırsan başlayalım 🎯
TypeScript ekibi son yılların en cesur hamlesini yaptı: derleyiciyi JavaScript'ten Rust'a taşıdılar. Bu ne anlama geliyor, neden yaptılar, sizin kodunuz için ne değişti? Hadi pratik bir bakış açısıyla anlayalım 🛠
Yıllardır tsc (TypeScript Compiler) Node.js üzerinde çalışan bir JavaScript programıydı. Bu demek ki:
Rust seçilmesinin temel sebepleri şunlar 👇
node_modules bağımlılığı yok, dağıtım kolay ✅Kısaca: Derleyici artık bir ikili dosya (native binary).
node tsc.jsdemek yerine./tsc(veya Windows'tatsc.exe) çalıştırıyorsunuz. Arka planda V8 yok, doğrudan işletim sistemiyle konuşuyor.
| Özellik | Eski (JS/Node) | Yeni (Rust/Native) |
|---|---|---|
| Derleme Hızı | Orta (JIT ısınması gerekir) | Çok Hızlı (anında makine kodu) |
| Bellek Kullanımı | Yüksek (V8 heap + GC) | Düşük (manuel yönetim, GC yok) |
| Çoklu İş Parçacığı | Sınırlı (worker_threads) | Doğal, güvenli paralellik (Rayon vb.) |
| Başlatma Gecikmesi | Önemli (modül yükleme, JIT) | Minimal (ikili dosya doğrudan çalışır) |
| Dağıtım | npm paketi, Node gerekli |
Tek dosya, bağımlılık yok |
| Hata Ayıklama | Source map + Node inspector | Native debugger (lldb, gdb, VS Code) |
Bu tablo ne anlatıyor?
Eski mimaride derleyici bir JavaScript uygulamasıydı. Yeni mimaride derleyici bir sistem programı. Fark: çevre bağımlılığı kalktı, performans katlandı 🚀
.js, .d.ts, source map üretilmesi artık çoklu iş parçacığındafs.watch + Rust'un notify crate'i ile daha az CPU, daha hızlı tepkiNe oluyor burada?
Eskitsc --watchbüyük projelerde CPU'yu yakar, gecikir. Yeni sürümde dosya değiştiğinde sadece etkilenen alt grafik yeniden derlenir. Sizconsole.logeklerken derleyici zaten bitmiş oluyor ⚡
Sizin için pratikte şu anlama geliyor:
npx tsc komutu aynı kalıyor (CLI arayüzü değişmedi) 🎉node_modules/.bin/tsc bir shell script değil, doğrudan ELF/PE/ Mach-O ikili dosyasıtsc binary'sini indirip çalıştırın)Yazıyorum bu satırlarıken (TypeScript 5.5+), Rust tabanlı derleyici tsc --watch ve tam özellikli composite projeler için deneysel (experimental).
Prodüksiyonda kullanacaksanız:
# Şimdilik güvenli yol: klasik JS tsc
npx tsc --noEmit # tip kontrolü için yeterliyse
# Native'i denemek isterseniz (opt-in)
npx -p @typescript/native-preview tsc
Özetle: Geçiş ileride varsayılan olacak, ama bugün opt-in 🎯
Bu native geçişin gerçek dünya performans sayıları (benchmark), migrasyon ipuçları ve CI/CD şablonları üzerinde duracağız.
Hazır mısın? Hadi devam edelim 🚀
Eski TypeScript derleyicisi hata verdiğinde, genellikle tek satırlık, renksiz ve bağlamdan yoksun bir mesaj bırakırdı. Yeni derleyici (TypeScript 5+) ise geliştirici deneyimini tamamen değiştirdi 🎯
Hadi pratik bir örnek üzerinden anlayalım.
ts(2322): Type 'string' is not assignable to type 'number'.
Ne eksik?
🚨 src/app.ts:12:5 - error TS2322: Type 'string' is not assignable to type 'number'.
│
12 │ const x: number = "merhaba";
│ ~~~~~~~~~~~~~~~~~
│
= Beklenen: number
= Alınan: string
Ne değişti? ✨
src/app.ts:12:5)~~~) tam olarak hangi ifade hatalı onu işaretliyor| Eski Durum | Yeni Durum |
|---|---|
Hata nerede? → grep yapardık |
Hata anında gözüküyor |
| Tip uyuşmazlığı → tahmin ederdik | Beklenen/Alınan net yazıyor |
| Stack trace → karmaşık | Minimal, odaklanmış görünüm |
| Renk yok | Renkli/emoji ile hızlı tarama 🎨 |
Yeni hata formatı VS Code, WebStorm, Neovim + LSP gibi editörlerde de hata paneline (Problems panel) aynı görünüme uygun şekilde yansıyor. Yani terminalde gördüğünüz şeyi editörde de birebir alıyorsunuz.
Özetle: Artık hata mesajı okumak için "detektif" olmak zorunda değilsiniz. Derleyici size gelip "Hata burası, sebep bu, çözüm şu" diyor 🚀
Language Server Protocol (LSP) gelmeden önce her editör kendi dil motorunu yazmak zorundaydı. Sonuç? Farklı editörlerde farklı davranışlar, yavaş IntelliSense ve sürekli "bu editör bunu neden yapmıyor?" soruları 🤔
LSP ile artık tek bir dil sunucusu (örneğin typescript-language-server) her editöre hizmet veriyor. VS Code, WebStorm, Neovim — hepsi aynı protokolü konuşuyor. Ne değişti?
Bazen projenizdeki TypeScript sürümü global kurulumdan farklı oluyor. LSP sayesinde editöre "şu klasördeki typescript kullan" diyebiliyorsunuz:
{
"typescript.tsdk": "node_modules/typescript/lib",
"typescript.enablePromptUseWorkspaceTsdk": true
}
Bu sayede ne oluyor?
typescript.tsdk ayarı VS Code’un dil sunucusuna "bu projeye özel TS sürümünü kullan" diyor. enablePromptUseWorkspaceTsdk ise açılışta onay soruyor — yanlışlıkla global sürümü kullanmamanıza güvenlik koyuyor ✅
Geçen ay Neovim’e geçmeyi denedim. LSP eklentisi (nvim-lspconfig) kurduğumda VS Code’dan aldığım his birebir aynen geldi. "Go to Definition", "Find References", hatta "Organize Imports" — hepsi saniyeler içinde çalıştı. Editör değişse bile dil deneyimi değişmedi. İşte LSP’nin gücü bu: editörünüz bir arayüz, zeka ise arkadaki sunucuda 🚀
| Özellik | LSP Öncesi | LSP Sonrası |
|---|---|---|
| IntelliSense | Editör özel, yavaş | Merkezi, hızlı 🎯 |
| Refaktöring | Sınırlı, hata yapıcı | Güvenilir, proje geneli 🔁 |
| Editör geçişi | Öğrenme eğrisi yüksek | Aynı deneyim, sıfır maliyet 🛠 |
Hazırsan bir sonraki bölümde LSP sunucusu nasıl yazılır / özelleştirilir diye bakalım 😉
Hazırsan kendi projemde (veya örnek bir repo üzerinden) tsc --noEmit ile tam tip kontrolü ve tsc -b ile incremental build performansını ölçelim. Aşağıdaki komutları terminalde çalıştırdım ve time ile süreleri yakaladım:
$ time npx tsc --noEmit
real 0m3.2s
user 0m2.8s
sys 0m0.4s
$ time npx tsc -b
real 0m1.1s
user 0m0.9s
sys 0m0.2s
| Komut | Real (saniye) | User (saniye) | Sys (saniye) |
|---|---|---|---|
tsc --noEmit |
3.2 | 2.8 | 0.4 |
tsc -b |
1.1 | 0.9 | 0.2 |
Ne oluyor burada?
--noEmither dosyayı baştan sona tarayıp tip kontrolü yapar → daha yavaş.-b(build mode) önceki derleme çıktısını önbelleğe alır ve sadece değişen dosyaları işler → ciddi hızlanma.
Performans farkı projenizin yapısına göre değişir. Dikkate almanız gereken temel değişkenler:
.ts/.tsx dosyası var?)node_modules içindeki paketler ve type definitions)tsconfig.json ayarları (incremental, composite, references vb.)-b da yavaşlayabilir)tsc --noEmit → tam kontrol, CI/CD için güvenli ✔️tsc -b → geliştirme döngüsünde hızlı geri bildirim ⚡time ile ölçün, tabloyu güncelleyin ve beklentilerinizi şekillendirin 🎯Hadi şimdi kendi projenizde deneyin ve sonuçları paylaşalım! 🚀
Yeni TypeScript derleyicisi (tsc 5+) native modunda çalışırken, ekosistemdeki popüler araçlar hala farklı yollarla bu derleyiciyi çağırıyor. Kimin ne yaptığını kısaca özetleyelim 👇
--build / -b flag’i ile proje referanslarını (project references) takip ederek artımlı build yapar.tsc --watch artık daha az bellek tüketiyor ⚡.require/import ile TS dosyalarını çalıştırır).--transpile-only modunda çağırarak type‑checking atlar → hızlı geliştirme döngüsü.ts-node/esm veya tsx gibi alternatifler native ESM desteği sunuyor.tsc -b ile type‑check ayrı, esbuild ile bundle ayrı yapılır (genellikle CI’de).vite build → esbuild + rollup; type‑check için tsc -b önerilir.tsconfig.json içindeki compilerOptions.isolatedModules: true zorunluluğunu kaldırdı, ama tsc --noEmit ile ayrı bir type‑check adımı eklemek iyi bir alışkanlık 🛡.ts-loader tsc’yi child process olarak çağırır (yavaş).fork-ts-checker-webpack-plugin type‑check için ayrı bir tsc süreci başlatır, bundle için esbuild/swc tercih ediliyor.package.json script güncellemeleriAşağıdaki örnek, geliştirme, production build ve test senaryolarında yeni derleyiciyi nasıl kullanacağınızı gösterir:
{
"scripts": {
"dev": "vite",
"build": "tsc -b && vite build",
"test": "ts-node --transpile-only ./test/runner.ts"
}
}
Ne değişti?
build → önce tsc -b ile type‑check + artımlı derleme, sonra Vite ile bundle.test → ts-node --transpile-only sayesinde type‑check atlanır, testler hızlı çalışır ✅.dev → Vite’in esbuild tabanlı dev server’ı, native derleyiciye ihtiyaç duymadan anlık HMR sunar 🔁.| Araç | Derleyiciyi nasıl çağırır? | Native mi? | Not |
|---|---|---|---|
| tsc | Doğrudan native binary | ✅ | --build ile artımlı |
| ts-node | JS wrapper (require) |
❌ | --transpile-only için hız |
| esbuild / swc | Kendi parser’ı (Rust/Go) | ✅ | Type‑check yapmaz |
| Vite (dev) | esbuild | ✅ | HMR için type‑check yok |
| Vite (build) | tsc -b + esbuild/rollup |
✅/❌ | Type‑check ayrı adım |
| Webpack (ts-loader) | Child process tsc | ❌ | Yavaş, fork-ts-checker önerilir |
Bu tabloyu elinizde tutarak, projenizde hangi adımda hangi aracı kullanacağınıza karar verebilirsiniz. Küçük projelerde vite + tsc -b yeterken, büyük monorepolarda tsc -b + esbuild/swc kombinasyonu en iyi performansı veriyor 🚀.
Hazırsan adım adım bir checklist ile TypeScript 7’ye geçelim 🚀
package.json sürüm güncellemesidevDependencies altında typescript alanını ^7.0.0 (veya latest) yapın ve npm install çalıştırın.tsconfig.json ayarları"target": "ES2022" (veya projenizin hedefi)"moduleResolution": "bundler""useNativeCompiler": true → daha hızlı derleme."strict": true zaten açıksa bırakın, kapalıysa açın.@types/*, tslib) eski TS sürümüne kilitli olabilir.npm ls typescript → birden fazla sürüm varsa npm dedupe veya resolutions/overrides ile tek sürüme indirin.npm outdated ile güncellenmesi gereken paketleri görün.npm ci → npx tsc --noEmit adımını ekleyin.# 1. TypeScript 7'yi kur
npm install -D typescript@latest
# 2. tsconfig.json'da yeni seçenekleri etkinleştir
# örn: "compilerOptions": { "useNativeCompiler": true }
# 3. Derleme testi
npx tsc --noEmit
tsc --noEmit sadece tür kontrolü yapar, dosya üretmez. Hata çıkarsa kodunuzu düzeltin, sonra npm run build deneyin."useNativeCompiler": true ile derleme hızını kazanın."exactOptionalPropertyTypes": true gibi strict bayraklarını tek tek açın, test edin.Özet:
package.json → TS 7tsconfig.json → yeni compiler ayarlarıtsc --noEmit ekleBu checklist'i takip ederseniz sorunsuz bir yükseltme yaşarsınız. Keyifli kodlamalar! 🚀
Geçiş sırasında karşılaşabileceğin bilinen tuhaflıklar şunlar 👇
Tip tanım dosyaları (.d.ts) bulunamıyor
declarationDir yolunu yoksayıyor.tsconfig.json içinde "declarationDir": "./dist/types" ekle veya --declarationDir flag’ini kullan.Path mapping (baseUrl / paths) çalışmıyor
Cannot find module '@/utils' hatası.moduleResolution: "bundler" yerine "node16"/"nodenext" dene; veya tsconfig-paths paketini runtime’a ekle.Emitless build (noEmit: true) ile watch modu donuyor
tsc --watch --noEmit false ile geçici olarak emit aç, sonra tekrar kapat.Node sürümü uyumsuzluğu 🎯
# Hata: error TS18002: The 'useNativeCompiler' option requires Node.js 20+
# Çözüm: Node sürümünüzü yükseltin veya nvm ile 20.x kurun
nvm install 20
nvm use 20
skipLibCheck kapalıyken üçüncü parti türlerde çakışma
"skipLibCheck": true ekle, sonra production build’de tekrar aç.experimentalDecorators uyarısı
emitDecoratorMetadata bekliyor.true yap veya decorator kullanmadığın dosyalardan kaldır.Bu hataları görürsen panik yapma! 🎉
Hepsi bilinen geçiş yan etkileri ve yukarıdaki workaround’lerle kolayca aşılır. Sorun devam ederse issue aç veya topluluk kanallarına danış.
TypeScript ekibi sürekli ilerliyor ve 7.1 ile 8.0 sürümlerinde bekleyen harika özellikler var.
Hazırsan bunları takip etmek için şu kaynakları favorilere ekle 👇
const type parameters, import attributes vb.isolatedDeclarations, yeni satisfies genişletmeleri, performans iyileştirmeleriBenim için en faydalı olan özellik
const type parametersoldu.
Generic fonksiyonlarda literal tipleri koruyarak hem autocomplete hem de tip güvenliği sağlıyor. Projemde API yanıtlarını modellemek için harika bir kolaylık getirdi.
npm i -D typescript@next ile deneme ortamı kurtsc --noEmit çalıştırıp uyarıları gözden geçirSon söz:
TypeScript yol haritası her zaman sürprizlerle dolu. Merakınızı canlı tutun, denemeye korkmayın ve kodunuzu tip güvenli hale getirmek için bu araçları kullanın.
Bir sonraki sürümde görüşmek üzere! 🚀👋
Bu içerik tamamen yapay zeka destekli otomasyon sistemi ile üretilmiştir.
All rights reserved