TypeScript 6.0 RC Duyuruldu: 7.0'a Hazırlık Sürümü

⏱️ 7 dk okuma📅 17 Ağustos 2026

TypeScript ekibi, 6.0 sürümünün Release Candidate (RC) aşamasına ulaştığını duyurdu. Bu sürüm, mevcut JavaScript tabanlı kod tabanı üzerine inşa edilen son büyük sürüm. Sıradaki adım, Go diliyle yeniden yazılan yerel derleyici üzerine kurulacak TypeScript 7.0. Yani 6.0, 5.9 ile 7.0 arasında bir geçiş köprüsü işlevi görüyor ve içerdiği pek çok değişiklik doğrudan 7.0 uyumunu hedefliyor. RC sürümünü denemek için npm install -D typescript@rc komutu kullanılabilir.

Beta’dan bu yana değişenler

Beta sonrasında öne çıkan düzeltmelerden biri, jenerik çağrılardaki (özellikle jenerik JSX ifadelerinde) fonksiyon ifadelerinin tip kontrolüne yönelik. Bu değişiklikle mevcut kodda daha fazla hata yakalanıyor; bazı jenerik çağrılarda açık tip argümanı vermek gerekebiliyor. import... assert {...} sözdiziminin kullanımdan kaldırılma kapsamı, import(..., { assert: {...}}) biçimindeki dinamik import() çağrılarını da kapsayacak şekilde genişletildi. DOM tipleri güncel web standartlarına göre yenilendi; Temporal API tanımlarında da ayarlamalar yapıldı.

`this` kullanmayan fonksiyonlarda daha az bağlam duyarlılığı

TypeScript, parametreleri açıkça yazılmamış fonksiyonlar için tipleri beklenen tipten veya aynı çağrının diğer argümanlarından çıkarabiliyor. Ancak jenerik çağrılarda “bağlam duyarlı” (contextually sensitive) fonksiyonlar özel muameleye tabi: derleyici, T için aday belirlerken parametre tipleri açık olmayan fonksiyonları önce atlıyor, önce diğer argümanlardan çıkarım yapıyor, sonra bu fonksiyonlara geri dönüyor.

Şu örnek durumu netleştiriyor:

declare function callIt<T>(obj: {
produce: (x: number) => T,
consume: (y: T) => void,
}): void;
// Ok syntax - sorunsuz
callIt({
consume: y => y.toFixed(),
produce: (x: number) => x * 2,
});
// Metot syntax - hata
callIt({
consume(y) { return y.toFixed(); },
//                  ~ 'y' is of type 'unknown'.
produce(x: number) { return x * 2; },
});

Farkın nedeni ince: metot sözdizimiyle yazılan fonksiyonların örtük bir this parametresi var, ok fonksiyonlarının ise yok. Bu this kullanılabilir olma potansiyeli, fonksiyonu bağlam duyarlı sınıfa sokuyor. TypeScript 6.0, fonksiyon gövdesinde this gerçekten kullanılmıyorsa bu fonksiyonu artık bağlam duyarlı saymıyor. Böylece tip çıkarımında öncelik alıyor ve yukarıdaki iki örnek de sorunsuz çalışıyor. Bu geliştirme Mateusz Burzyński katkısıyla, ilgili PR üzerinden yapıldı.

`#/` ile başlayan subpath import desteği

Node.js’in subpath imports özelliği, paketlerin package.json içindeki imports alanı üzerinden kendi modüllerine dahili takma ad tanımlamasına izin veriyor. Örneğin:

{
"name": "my-package",
"type": "module",
"imports": {
"#root": "./dist/index.js",
"#root/*": "./dist/*"
}
}

Daha önce bu takma adların # karakterinden sonra bir isim segmenti içermesi gerekiyordu; yani salt #/ ile başlayan bir eşleme mümkün değildi. Bundler dünyasında yaygın olan @/ benzeri kısa önekleri sevenler için bu sürtünme noktasıydı. Node.js kısa süre önce doğrudan #/ ile başlayan subpath importlarını destekler hale getirdi:

{
"name": "my-package",
"type": "module",
"imports": {
"#": "./dist/index.js",
"#/*": "./dist/*"
}
}

TypeScript 6.0 da bu davranışı --moduleResolution ayarının node20, nodenext ve bundler değerleri altında destekliyor. Katkı magic-akari tarafından, bu PR ile yapıldı.

`--moduleResolution bundler` ile `--module commonjs` kombinasyonu

Daha önce --moduleResolution bundler yalnızca --module esnext veya --module preserve ile kullanılabiliyordu. --moduleResolution node (yani node10) kullanımdan kaldırıldığı için, birçok proje için yeni önerilen yükseltme yolu olarak bundler çözümlemesinin commonjs modülüyle birlikte kullanılabilmesi de mümkün hale geldi. Proje tipine göre (bundle edilmiş web uygulaması, Bun uygulaması veya Node.js uygulaması) tavsiye edilen hedef, --module preserve + --moduleResolution bundler veya --module nodenext yönünde bir plan olmayı sürdürüyor. Ayrıntılar ilgili PR içinde.

`--stableTypeOrdering` bayrağı

TypeScript bugüne kadar tip kimliklerini (dahili takip numaraları) türlerle karşılaştığı sıraya göre atıyor ve union tipleri bu kimliklere göre tutarlı biçimde sıralıyor. Aynı süreç özellikler için de geçerli. Bu, program içindeki bildirim sırasının bildirim çıktısı gibi yerlerde beklenmedik etkiler doğurabileceği anlamına geliyor:

// Girdi
export function foo(condition: boolean) {
return condition ? 100 : 500;
}
// Çıktı: 100 | 500

Aynı dosyanın üstüne alakasız bir const x = 500; eklendiğinde çıktı 500 | 100 haline gelebiliyor; çünkü 500 literal tipi önce işlendiği için daha küçük bir kimliğe sahip oluyor. Nadir durumlarda bu sıralama farkı hataların ortaya çıkıp kaybolmasına bile yol açabiliyor.

TypeScript 7’nin büyük mimari iyileştirmelerinden biri paralel tip denetimi. Paralellik, farklı denetçilerin düğümleri, tipleri ve sembolleri farklı sıralarda ziyaret etmesi demek; bu da mevcut şemada belirsizliğe yol açardı. Bunu çözmek için TypeScript 7.0, dahili nesneleri (tipler, semboller) içeriklerine dayanan deterministik bir algoritmaya göre sıralıyor. Böylece aynı programda hangi denetleyicinin hangi sırada çalıştığından bağımsız olarak sonuç aynı kalıyor. Yukarıdaki örnekte TypeScript 7 her zaman 100 | 500 yazacak.

Bu durum, 6.0 ile 7.0 arasında çıktı sıralaması farklılıklarının doğal olarak ortaya çıkabileceği anlamına geliyor. Karşılaştırmayı kolaylaştırmak için 6.0’a --stableTypeOrdering bayrağı eklendi. Bayrak, 6.0’ın sıralama davranışını 7.0’ınkiyle eşleştiriyor. Ancak sürekli açık tutulması önerilmiyor; kod tabanına bağlı olarak tip denetimini kayda değer ölçüde (yaklaşık dörtte bir oranına kadar) yavaşlatabiliyor.

--stableTypeOrdering ile bir hata görülüyorsa bunun genellikle çıkarım farklılıklarından kaynaklandığı belirtiliyor. Çözüm için çoğunlukla açık bir tip belirtmek yeterli oluyor:

- someFunctionCall(/*...*/);
+ someFunctionCall<SomeExplicitType>(/*...*/);

veya çağrıya geçilecek argüman için değişken düzeyinde açıklama:

- const someVariable = { /*...*/ };
+ const someVariable: SomeExplicitType = { /*...*/ };
someFunctionCall(someVariable);

Bu bayrak yalnızca 6.0-7.0 farklarını teşhis için düşünüldü; kalıcı bir özellik olarak tasarlanmadı. Ayrıntı ilgili PR’da.

`target` ve `lib` için `es2025` desteği

TypeScript 6.0 hem target hem de lib için es2025 değerini destekliyor. ES2025 yeni bir dil özelliği getirmiyor; ancak RegExp.escape gibi yerleşik API’lere yönelik tip eklemeleri içeriyor ve Promise.try, Iterator yöntemleri, Set yöntemleri gibi bazı bildirimleri esnext‘ten es2025‘e taşıyor. Bu hedefin etkinleştirilmesi Kenta Moriuchi’nin katkısıyla, ilgili PR ile gerçekleşti.

`Temporal` için yerleşik tipler

Uzun süredir beklenen Temporal önerisi 3. aşamaya ulaştı ve JavaScript’e yakın gelecekte eklenmesi bekleniyor. TypeScript 6.0 artık Temporal API için yerleşik tipler barındırıyor; --target esnext veya "lib": ["esnext"] (ya da daha dar kapsamlı esnext.temporal) ile kullanılabiliyor:

let yesterday = Temporal.Now.instant().subtract({ hours: 24 });
let tomorrow = Temporal.Now.instant().add({ hours: 24 });
console.log(`Yesterday: ${yesterday}`);
console.log(`Tomorrow: ${tomorrow}`);

Temporal, çeşitli çalışma zamanlarında zaten kullanılabiliyor. Katkı Renegade334 kullanıcısına ait.

“Upsert” yöntemleri: `getOrInsert` ve `getOrInsertComputed`

Map yapılarında sık karşılaşılan bir desen, bir anahtarın varlığını kontrol edip yoksa varsayılan bir değer atamak ve okumak. Bu deseni sadeleştirmek için ECMAScript’in “upsert” önerisi 4. aşamaya ulaştı ve Map ile WeakMap‘e iki yöntem ekliyor: getOrInsert ve getOrInsertComputed. Bu yöntemler TypeScript 6.0’da esnext lib içine dahil edildi.

function processOptions(compilerOptions: Map<string, unknown>) {
let strictValue = compilerOptions.getOrInsert("strict", true);
//...
}

getOrInsertComputed ise varsayılan değerin hesaplanması pahalı olduğu (yoğun hesaplama, tahsis, uzun süren senkron I/O) durumlar için tasarlandı. Bir callback alıyor ve anahtar yoksa yalnızca o zaman çağırıyor; callback’e anahtarın kendisi de argüman olarak veriliyor:

someMap.getOrInsertComputed(someKey, computeSomeExpensiveDefaultValue);

Katkı Renegade334 tarafından yapıldı.

`RegExp.escape`

Bir literal metni düzenli ifade içinde eşleştirmek gerektiğinde *, +, ?, (, ) gibi özel karakterlerin kaçış işlemi zorunlu. 4. aşamaya ulaşan RegExp Escaping önerisi, bu işi devralan RegExp.escape fonksiyonunu getiriyor:

function matchWholeWord(word: string, text: string) {
const escapedWord = RegExp.escape(word);
const regex = new RegExp(`\\b${escapedWord}\\b`, "g");
return text.match(regex);
}

RegExp.escape, es2025 lib içinde tanımlı olduğu için TypeScript 6.0 ile birlikte kullanıma açık. Katkı Kenta Moriuchi tarafından yapıldı.

`dom` lib artık `dom.iterable` ve `dom.asynciterable` içeriyor

Önceden DOM API’leri, Iterable ve AsyncIterable desteği bulunmayan ortamlar için dom.iterable ve dom.asynciterable olmak üzere kısmen ayrıştırılıyordu. Bu durum, NodeList veya HTMLCollection gibi DOM koleksiyonlarında yineleme yapabilmek için dom.iterable‘ı açıkça eklemeyi gerektiriyordu.

TypeScript 6.0’da lib.dom.iterable.d.ts ve lib.dom.asynciterable.d.ts içerikleri tamamen lib.dom.d.ts‘ye dahil edildi. Yapılandırma dosyanızın "lib" dizisinde bu isimlere referans vermeye devam edebilirsiniz; ancak artık boş dosyalar olarak duruyorlar.

// Önceden "lib": ["dom", "dom.iterable"] gerekiyordu.
// Artık "lib": ["dom"] yeterli.
for (const element of document.querySelectorAll("div")) {
console.log(element.textContent);
}

Halihazırda hem dom hem de dom.iterable ekleyen projeler, artık yalnızca dom ile devam edebilir. Ayrıntılar ilgili PR üzerinden takip edilebilir.

7.0’a geçiş perspektifi

TypeScript 6.0’ın işlevi, mevcut TypeScript kod tabanını Go ile yeniden yazılan yerel derleyiciye geçişte kullanıcıları hazırlamak. Bu nedenle sürümdeki değişikliklerin önemli bir kısmı 7.0 davranışıyla uyumu artırmayı hedefliyor: --stableTypeOrdering gibi bayraklar, bağlam duyarlılığındaki ince ayarlar, modül çözümleme kombinasyonlarındaki güncellemeler ve DOM lib sadeleştirmesi bunun örnekleri.

Kaynaklar ve İleri Okuma

Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102