TypeScript 6.0 Beta: 7.0'a Geçiş Köprüsü

⏱️ 6 dk okuma📅 22 Ağustos 2026

TypeScript 6.0 Beta yayımlandı. Ekibin ifadesiyle bu sürüm, mevcut JavaScript kod tabanına dayanan son ana sürüm. Duyuruya göre yeni Go tabanlı derleyici ve dil servisi kod tabanı TypeScript 7.0’ın temeli olacak; 6.0 ise 5.9 ile 7.0 arasında bir köprü işlevi görüyor. Bu yüzden sürümdeki değişikliklerin büyük kısmı 7.0’a uyum ve hazırlığı hedefliyor. Beta’yı denemek için paket şu komutla kurulabilir:

npm install -D typescript@beta

this kullanmayan fonksiyonlarda bağlamsal duyarlılığın gevşemesi

TypeScript, açık tip belirtilmemiş parametreleri çoğunlukla beklenen tipten veya aynı çağrıdaki diğer argümanlardan çıkarabiliyor. Ancak generic bir fonksiyona geçirilen nesnede metotların sırası, method syntax kullanıldığında beklenmedik sonuçlar doğurabiliyordu. Aşağıdaki örnek durumu özetliyor:

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

Sorunun kökeni ince bir ayrıntıda: method syntax ile yazılan fonksiyonların örtük bir this parametresi vardır, arrow fonksiyonlarında ise yoktur. Derleyici, tip argümanı çıkarımı sırasında bağlamsal olarak duyarlı fonksiyonları (parametrelerinin tipi açıkça belirtilmemiş olanları) atlayıp önce diğer argümanlardan çıkarım yapar. this ihtimali bu duyarlılığı tetikleyen etkenlerden biri.

TypeScript 6.0, bir fonksiyonun gövdesinde this gerçekten kullanılmıyorsa bu fonksiyonu bağlamsal olarak duyarlı saymıyor. Böylece tip çıkarımında daha yüksek önceliğe kavuşuyor ve yukarıdaki method syntax örneği artık çalışıyor. Değişiklik Mateusz Burzyński‘nin katkısıyla geldi.

#/ ile başlayan subpath import’lar

Node.js’in modül desteğiyle birlikte gelen subpath imports özelliği, paketlerin package.json içindeki imports alanı üzerinden kendi içlerinde iç takma adlar tanımlamasına olanak tanıyor. Örnek:

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

Bu yapı sayesinde ../../utils.js gibi göreli yollar yerine #root/utils.js yazılabiliyor. Ancak # karakterinden sonra bir segment yazma zorunluluğu, özellikle bundler dünyasındaki @/ alışkanlığıyla karşılaştırıldığında gereksiz bir kısıtlamaydı. Node.js kısa süre önce #/ ile başlayan subpath import’ları desteklemeye başladı:

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

Duyuruya göre bu davranış yeni Node.js 20 sürümlerinde destekleniyor; TypeScript de bunu --moduleResolution için node20, nodenext ve bundler seçenekleri altında tanıyor. Katkı magic-akari‘ye ait, ilgili PR burada.

–moduleResolution bundler ile –module commonjs uyumu

Önceden --moduleResolution bundler yalnızca --module esnext veya --module preserve ile birlikte kullanılabiliyordu. --moduleResolution node (yani node10) kullanımdan kaldırıldığı için bundler ile commonjs kombinasyonu birçok proje için uygun bir yükseltme yolu haline geldi. Duyuru; proje türüne göre --module preserve + --moduleResolution bundler ya da --module nodenext hedeflerine geçişi planlamayı öneriyor. Ayrıntılar ilgili PR’da.

Yeni –stableTypeOrdering bayrağı

TypeScript, tiplere karşılaşma sırasına göre iç ID’ler atıyor ve union tiplerini bu ID’lere göre sıralıyor. Bu, aynı program içinde yeni bir bildirim eklendiğinde çıkarım sonucunun sıralamasının değişmesine yol açabiliyor:

// Input
export function foo(condition: boolean) {
return condition ? 100 : 500;
}
// Output
export declare function foo(condition: boolean): 100 | 500;

// Input
const x = 500;
export function foo(condition: boolean) {
return condition ? 100 : 500;
}
// Output
export declare function foo(condition: boolean): 500 | 100;

TypeScript 7’nin getirdiği paralel tip kontrolü, farklı checker’ların düğümleri, tipleri ve sembolleri farklı sıralarla ziyaret etmesine yol açıyor; bu da deterministik olmayan çıktı riski doğuruyor. Bunu önlemek için 7.0, iç nesneleri içeriklerine dayanan deterministik bir algoritmayla sıralıyor. Yukarıdaki örnekte 7.0 her zaman 100 | 500 üretiyor.

6.0 ile 7.0 arasındaki çıktı sıralaması farklılıklarının doğurduğu “gürültü”yü azaltmak için 6.0’a --stableTypeOrdering bayrağı eklendi. Bu bayrak, 6.0’ın sıralama davranışını 7.0’ınkine yaklaştırıyor. Duyuruda bayrağın sürekli kullanımı önerilmiyor, çünkü tip kontrolünde kod tabanına bağlı olarak %25’e varan yavaşlamaya neden olabiliyor.

Bayrak açıldığında çıkarım farklılığından kaynaklanan tip hataları belirebiliyor. Bu durumda genellikle açık bir tip vermek çözüm oluyor; örneğin bir tip argümanı:

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

ya da geçirilen argümana açık bir tip anotasyonu:

- const someVariable = { /*... karmaşık nesne...*/ };
+ const someVariable: SomeExplicitType = { /*... karmaşık nesne...*/ };
someFunctionCall(someVariable);

Bayrak yalnızca 6.0 ile 7.0 arasındaki farkları teşhis etmeye yardımcı olmak için tasarlandı; uzun vadeli bir özellik olarak konumlandırılmıyor. Ayrıntı için ilgili PR.

target ve lib için es2025 desteği

TypeScript 6.0 hem target hem de lib için es2025 seçeneğini destekliyor. ES2025 yeni bir dil özelliği getirmese de yerleşik API’ler için yeni tipler tanımlıyor (örneğin RegExp.escape) ve Promise.try, Iterator yöntemleri ile Set yöntemleri gibi bazı bildirimleri esnext‘ten es2025‘e taşıyor. Katkı Kenta Moriuchi’ye ait.

Temporal API için yerleşik tipler

Stage 3’e ulaşan Temporal önerisi için TypeScript 6.0 artık yerleşik tipler içeriyor. --target esnext veya "lib": ["esnext"] (ya da daha ince taneli temporal.esnext) 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}`);

Duyuruya göre Temporal çeşitli çalışma zamanlarında zaten kullanılabilir durumda. Katkı GitHub kullanıcısı Renegade334 tarafından yapıldı.

Map/WeakMap için “upsert” yöntem tipleri

Map üzerinde sıkça karşılaşılan “anahtar varsa getir, yoksa ekleyip getir” desenini kısaltan ECMAScript “upsert” önerisi stage 4’e ulaştı ve iki yeni yöntem getiriyor:

getOrInsert
getOrInsertComputed

Bu yöntemler esnext lib’ine eklendi. Klasik desen:

function processOptions(compilerOptions: Map<string, unknown>) {
let strictValue: unknown;
if (compilerOptions.has("strict")) {
strictValue = compilerOptions.get("strict");
}
else {
strictValue = true;
compilerOptions.set("strict", strictValue);
}
}

Artık şu şekle sadeleşebiliyor:

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

getOrInsertComputed ise varsayılan değerin hesaplanması maliyetli olduğunda kullanılıyor; sadece anahtar yoksa çağrılacak bir callback alıyor ve bu callback’e anahtar da argüman olarak veriliyor:

someMap.getOrInsertComputed(someKey, computeSomeExpensiveDefaultValue);
function computeSomeExpensiveValue(key: string) {
//...
}

Katkı Renegade334’a ait.

RegExp.escape

Stage 4’e ulaşan RegExp Escaping önerisi, düzenli ifade içinde kullanılacak bir metindeki özel karakterleri kaçış karakterine dönüştürme işini yerleşik hale getiriyor. es2025 lib’i ile birlikte artık TypeScript tarafında da kullanılabilir:

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

Katkı Kenta Moriuchi’ye ait.

dom artık dom.iterable ve dom.asynciterable’ı da kapsıyor

Önceden DOM API’lerinin iterasyon ve async iterasyon bölümleri, Iterable/AsyncIterable desteği olmayan ortamlar düşünülerek dom.iterable ve dom.asynciterable altında ayrıştırılmıştı. Bu durum, örneğin NodeList veya HTMLCollection üzerinde iterasyon yaparken lib dizisine ekstra bir giriş eklemeyi gerektiriyordu.

TypeScript 6.0 ile birlikte lib.dom.iterable.d.ts ve lib.dom.asynciterable.d.ts içerikleri tamamen lib.dom.d.ts‘e alındı. Bu iki isim hala "lib" dizisinde referans verilebiliyor ancak artık boş dosyalar:

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

Ayrıntı için ilgili PR.

7.0’a hazırlık sürümü olarak 6.0

Duyuruda vurgulandığı gibi TypeScript 6.0, TypeScript 5.9 ile API uyumluluğunu koruyor ve mevcut TypeScript bilgisiyle uyumlu kalıyor; fakat 7.0’a zemin hazırlamak için bir dizi kırıcı değişiklik ve kullanımdan kaldırma da içeriyor. Duyuru, TypeScript 5.0’dan bu yana geçen iki yılda JavaScript ekosistemindeki iki eğilime dikkat çekiyor: neredeyse tüm çalışma zamanlarının “evergreen” hale gelmesi ve ES5 gibi eski hedeflerin son derece azalması; bundler’lar ile ESM’in yeni projelerde en yaygın modül hedefine dönüşmesi, buna karşın CommonJS’in hala önemli bir hedef olarak kalması.

Kaynaklar ve İleri Okuma

github.com

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