TypeScript 7 Çıktı: 10x Hızlı Ama ESLint Kırılıyor

TypeScript 7.0, 8 Temmuz 2026'da genel kullanıma açıldı ve derleyiciyi Go'ya taşıyarak vscode gibi büyük projelerde 11,9 kata varan derleme hızı vaat ediyor. Ama bu hız bedelsiz değil: TypeScript 7.0 hiçbir programatik API ile gelmiyor, bu yüzden typescript-eslint gibi derleyicinin JavaScript tabanlı API'sine bağımlı araçlar şu an çalışmıyor. Bu yazıda TypeScript 7 geçiş breaking change'lerini, TypeScript 6 ile yan yana çalıştırma yöntemini ve hangi projelerin bugün, hangilerinin 7.1'i beklemesi gerektiğini kaynaklı şekilde masaya yatırıyoruz.

💡 Pro Tip: Yükseltmeden önce npm ls typescript ile hangi bağımlılıklarının derleyicinin programatik API'sine doğrudan eriştiğini kontrol et — typescript-eslint bu listede en sık kırılan araç.

İçindekiler

• TypeScript 7 Tek Bakışta
• Neden şimdi konuşuyoruz
• 10x Hız Nereden Geliyor: Go Portu ve tsgo
• Asıl Blokaj: API Yok
• Bu neden "tek bir bug" değil, bir mimari karar
• Varsayılan Değişiklikler: strict, ESNext, types ve rootDir
• Kaldırılan Hedefler ve Modül Sistemleri
• TypeScript 6 ile Yan Yana Çalıştırma
• Next.js'te Build Sırasında Tip Kontrolü
• Gerçek Bir Migrasyon: Adım Adım Uygulama
• Karar Tablosu: Hangi Proje Bugün Geçmeli
• SSS
• TypeScript 7'ye şimdi geçmeli miyim?
• TypeScript 7 neden API ile gelmiyor, hangi araçlar kırılıyor?
• TypeScript 6 ve 7 aynı projede birlikte çalıştırılabilir mi?
• TypeScript 7'de strict ve ESNext varsayılan olması neyi bozar?
• `@typescript/typescript6` paketini kurduktan sonra hangi komutu kullanmalıyım?
• 7.1 çıktığında geçiş nasıl tamamlanır?
• Güncelleme (Eylül 2026)
• Sonuç
• Kaynaklar

TypeScript 7 Tek Bakışta

Microsoft, resmi duyuruda "Today we are proud to announce the availability of TypeScript 7, a 10x faster native port of TypeScript!" diyerek TypeScript 7.0'ı 8 Temmuz 2026'da genel kullanıma açtı. "10x" ifadesi pazarlama başlığı; gerçek ölçülen hız artışı projeye göre 7,7x ile 11,9x arasında değişiyor.

Bu, TypeScript derleyicisinin JavaScript'ten Go'ya taşınan ilk tam native portu. Microsoft, duyurunun ifadesiyle geçen bir yıl boyunca kendi ekipleriyle (Loop, Office, PowerBI, Teams, Xbox) ve dışarıdan birçok büyük ekiple gerçek kod tabanları üzerinde TypeScript 7'yi test etti; Bloomberg, Canva, Figma, Slack ve Vercel gibi şirketler de bu doğrulama sürecine dahil oldu.

Bu kadar geniş bir doğrulama süreci tesadüf değil: derleyicinin mimarisini değiştirmek, sadece "aynı işi daha hızlı yapan" bir güncelleme değil — dil sunucusunun (LSP), editör entegrasyonlarının ve build araçlarının hepsinin yeniden test edilmesini gerektiren köklü bir değişim. Bu yüzden TypeScript 7'yi bir "patch" gibi değil, ekosistemin kademeli olarak uyum sağladığı bir platform geçişi gibi değerlendirmek daha doğru bir çerçeve.

Neden şimdi konuşuyoruz

TypeScript 7 geçiş breaking change listesi kısa ama etkisi büyük: varsayılan derleyici ayarları sıkılaştı, bazı hedefler tamamen kaldırıldı ve en önemlisi, derleyicinin programatik API'si bu sürümde yok. Bu üç değişiklik birlikte, "hemen mi geçmeliyim yoksa 7.1'i mi beklemeliyim" sorusunu her proje için farklı cevaplıyor.

10x Hız Nereden Geliyor: Go Portu ve tsgo

Native port, Microsoft'un microsoft/typescript-go adlı deposunda geliştirildi. Geliştirme sürecinde komut adı tsgo idi; TypeScript 7.0 RC ve sonrasında komut adı tekrar tsc oldu — yani günlük kullanımda hiçbir şeyi yeniden öğrenmen gerekmiyor.

Resmi duyurudaki ölçüm tablosu, gerçek projelerde ölçülen derleme sürelerini gösteriyor:

Bu sayıların uydurma olmadığını kendin de doğrulayabilirsin:

1// Kaynak: devblogs.microsoft.com/typescript/announcing-typescript-7-0/
2const before = 125.7; // vscode, TS 6.x derleme süresi (saniye)
3const after = 10.6; // vscode, TS 7.0 native derleme süresi (saniye)
4console.log((before / after).toFixed(1)); // "11.9"

vscode'u 8 tip-kontrol worker'ıyla derlediğinde (duyurunun "experimental" dediği --checkers bayrağıyla, --checkers 8; varsayılan 4) süre 7,51 saniyeye, hızlanma ise 16,7x'e çıkıyor — çok çekirdekli makinelerde ek kazanç sağlıyor, ama duyuruya göre artan bellek pahasına.

Bu tablodan çıkarılacak pratik ders şu: duyuru tam build'ler için "typically yield speedups between 8x and 12x" diyor, ama --checkers bölümünde "results will differ across projects and underlying machines" uyarısını da ekliyor — yani kendi projendeki oranı ölçmeden varsayma. Kazancın nereden geldiği ise duyuruda açıkça yazılı: "TypeScript 7.0 now performs many steps in parallel, including parsing, type-checking, and emitting."

Asıl Blokaj: API Yok

Hızdan daha önemli bir gerçek var ve çoğu "10x hız" başlıklı yazı bunu geçiştiriyor: Microsoft resmi duyuruda net konuşuyor — "While TypeScript 7.0 is here, it does not ship with an API. We expect TypeScript 7.1 to ship with a new (and different) API." Yani import * as ts from "typescript" ile derleyicinin iç yapısına programatik erişen her araç, TypeScript 7.0 üzerinde çalışamıyor.

Bunun en somut kurbanı typescript-eslint. Kütüphane, kod analizi için doğrudan derleyicinin JavaScript API'sine ihtiyaç duyuyor; 7.1 ile gelecek yeni API hazır olana kadar bu bağımlılık çözülmüş değil. Benzer şekilde ts-jest ve ts-morph gibi derleyici API'si üzerine kurulu araç zincirleri de aynı duvara çarpıyor.

Bu blokajın kayda geçmiş hâli de var: 8 Temmuz 2026'da açılan typescript-eslint #12518, [email protected] ile [email protected]'nin npm ci'da ERESOLVE verdiğini, lint'te ise TypeError: Cannot read properties of undefined (reading 'Cjs') ile çöktüğünü belgeliyor. Issue aynı gün "duplicate" etiketiyle kapatıldı (GitHub kapanış nedeni: not planned); maintainer'ın gerekçesi: "typescript-eslint isn't compatible with TS 7 at this time, because there is no TS 7 API at this time."

Aynı blokaj editörde de geçerli: TypeScript'i kendi derleyicisine gömen Volar gibi araçlar yalnız 6.0 API'sine dayanabildiği için duyuru, Vue, MDX, Astro ve Svelte projelerinin şimdilik 6.0'da kalması gerektiğini söylüyor; Angular'da öneri CLI'da TypeScript 7, editörde 6.0.

Pratikte bu, "TypeScript 7'ye geçtim ama npm run lint artık çalışmıyor" şeklinde bir hata olarak karşına çıkıyor — derleyicinin kendisi bozuk değil, typescript-eslint'in beklediği API yüzeyi ortada yok. Bu ayrımı net tutmak önemli: sorun senin kodunda değil, araç zincirinin TypeScript 7.0'ın henüz sunmadığı bir katmana bağımlı olmasında.

Bu neden "tek bir bug" değil, bir mimari karar

Go portu, TypeScript'in eski JavaScript tabanlı derleyici gövdesini tamamen değiştiriyor. Programatik API, bu yeni Go çekirdeğinin üzerine ayrıca inşa edilmesi gereken bir katman — Microsoft bunu bilinçli olarak 7.0'ın kapsamı dışında tuttu ve 7.1'e erteledi. Bu yüzden "ne zaman düzelecek" sorusunun cevabı bir bug-fix değil, bir sonraki minor sürüm.

Varsayılan Değişiklikler: strict, ESNext, types ve rootDir

TypeScript 7.0'ın tsconfig.json varsayılanları önceki sürümlere göre belirgin şekilde sıkılaştı. Resmi duyurunun "Updates Since 5.x, and New Behaviors from 6.0" bölümü "At a glance, the notable default changes to configuration are" başlığı altında sekiz varsayılan değişikliği sayıyor; duyuru bunlardan rootDir ve types değişikliklerini en "şaşırtıcı" olanlar sayıyor. Aşağıdaki tablo bunlardan dördünü topluyor:

Burada gözden kaçan önemli bir nüans var: tablodaki dört varsayılanı da TypeScript 7.0 icat etmedi, dördü de 6.0 ile geldi — duyurunun kendi ifadesiyle "TypeScript 7.0 adopts 6.0's new defaults". TypeScript 7.0'ın kendi eklediği şey, duyurunun aynı cümlesinin ikinci yarısında: "and provides hard errors in the face of any flags and constructs deprecated in TypeScript 6.0" — yani 6.0'da kullanımdan kaldırılmış bayrak ve yapılar artık sert derleme hatası veriyor. Yani "7.0'da strict varsayılan oldu" cümlesi teknik olarak yanlış; doğrusu "strict varsayılanı 6.0 ile geldi, 7.0 onu devraldı."

types alanının [] olması özellikle Node.js projelerinde global tip paketlerini (@types/node gibi) örtük olarak içeri almayı durduruyor — bu paketleri artık ya import etmen ya da types dizisine açıkça eklemen gerekiyor.

Kaldırılan Hedefler ve Modül Sistemleri

TypeScript 7 geçiş breaking change listesinin en sert kısmı burada: bazı eski hedef ve modül ayarları artık derleme hatası veriyor, uyarı değil. Resmi duyuru bu sert hataların tam listesini veriyor (downlevelIteration ve moduleResolution: classic de listede). Pratikte ilk kontrol edeceğin dördü şunlar:

• target: es5: artık desteklenmiyor (TypeScript 6.0 notlarına göre en düşük hedef ES2015).
• module: amd / umd / systemjs / none: hepsi kaldırıldı.
• moduleResolution: node / node10: kaldırıldı; önerilen değerler nodenext ve bundler.
• baseUrl: kaldırıldı; paths değerlerini proje köküne göreli yazman gerekiyor.

Bu kalemlerden herhangi birini kullanan bir tsconfig.json, TypeScript 7.0 ile derlenemiyor — geçiş öncesi ilk kontrol noktan burası olmalı:

1{
2  "compilerOptions": {
3    "target": "ES2020",
4    "module": "NodeNext",
5    "moduleResolution": "NodeNext",
6    "strict": true,
7    "types": ["node"]
8  }
9}

Eski bir projede grep -inE '"(target|module|moduleResolution|baseUrl)"[[:space:]]*:' tsconfig*.json komutu bu dört ayarın satırlarını numaralarıyla listeler. Desen yalnız anahtar adını eşlediği için değerin "ES5" mi "es5" mi yazıldığı sonucu etkilemez; çıkan satırları tek tek okuyup değerlerini kaldırılan listeyle karşılaştırman gerekiyor.

TypeScript 6 ile Yan Yana Çalıştırma

API eksikliğine karşı Microsoft boş durmadı: TypeScript 6.0'ın programatik API'sini yeniden dışa aktaran resmi bir uyumluluk paketi yayınladı. Duyuru şöyle diyor: "we've published a new compatibility package, @typescript/typescript6. This package provides an executable named tsc6... re-exports the TypeScript 6.0 API." Yani tsc6 komutuyla eski derleyiciyi, tsc komutuyla da yeni native derleyiciyi aynı makinede çalıştırabiliyorsun.

Kurulum resmi duyurudaki komutla birebir aynı:

1npm install -D typescript@npm:@typescript/typescript6

Bu paketi hem TS7'nin hız avantajını hem de typescript-eslint gibi API'ye ihtiyaç duyan araçları aynı projede tutmak için npm alias'larıyla birleştirebilirsin:

1{
2  "devDependencies": {
3    "typescript": "npm:@typescript/typescript6@^6.0.2",
4    "@typescript/native": "npm:typescript@^7.0.2"
5  }
6}

Bu düzende typescript paketini import eden araçlar (typescript-eslint dahil) TS 6.0 API'sini görür; npx tsc ise @typescript/native üzerinden TypeScript 7 native derleyicisini, tsc6 ise TS 6.0 derleyicisini çalıştırır. Çakışma olmuyor çünkü npm alias'ı paketleri farklı klasörlere kuruyor ve uyumluluk paketi ayrı bir tsc6 bin'i sağlıyor.

Bu yaklaşımın en büyük avantajı geri dönüşü olmaması gereken bir taahhüt istememesi: @typescript/typescript6 paketini kaldırıp typescript'i doğrudan npm:typescript@^7.0.2'ye çevirmek, 7.1'in API'si yayınlandığında tek satırlık bir package.json değişikliği. Yani bugün yan yana çalıştırma düzenine geçmek, seni gelecekte tam native geçişe kilitlemiyor — tam tersine, geçişi kademeli ve geri alınabilir hâle getiriyor.

Next.js'te Build Sırasında Tip Kontrolü

Next.js gibi framework'ler build sırasında tip kontrolünü genellikle derleyicinin programatik API'sini çağırarak yapıyordu — TypeScript 7.0'da bu API olmadığı için, bu yazının yayımlandığı tarih itibarıyla en sağlam yol build ile tip kontrolünü ayırmak; Next.js canary'sine 10 Temmuz'da inen experimental.useTypeScriptCli bayrağı o tarihte opt-in. Pratikte iki adım işe yarıyor: next.config içinde typescript.ignoreBuildErrors: true ayarıyla build'i tip hatasından bağımsızlaştırmak, ardından CI'da ayrı bir adımda tsc6 --noEmit (ya da API'ye ihtiyaç duymayan projelerde doğrudan tsc --noEmit) çalıştırarak tip güvenliğini korumak.

1# CI adımı: build hızlı native derleyiciyle, tip kontrolü ayrı process'te
2next build
3npx tsc6 --noEmit

Bu, framework'ün kendi entegrasyonunu beklemeden bugün uygulayabileceğin geçici ama sağlam bir köprü. Aynı prensip yalnızca Next.js'e özgü değil — herhangi bir build aracının (bundler, monorepo task runner, deploy pipeline) tip kontrolü için derleyici API'sini çağırdığı her yerde geçerli: build adımını hız için native derleyiciye, doğrulama adımını API'ye ihtiyaç duyan araca ayırmak, framework'ün resmi desteği gelene kadar seni bekletmeyen genel bir desen. Build ile CI pipeline'ını ayrı adımlara bölme yaklaşımını serverless bir TypeScript projesinde uçtan uca kurmak istersen Hono.js ile serverless production kurulumu yazısına bakabilirsin.

Gerçek Bir Migrasyon: Adım Adım Uygulama

Yukarıdaki tüm bilgiyi tek bir akışta birleştirelim. Bir Node.js/Next.js projesinde TypeScript 7 geçişini şu sırayla uygulaman, sürpriz breaking change'lerle karşılaşma riskini büyük ölçüde azaltır:

1. Envanter çıkar. npm ls typescript ve tsconfig.json dosyalarını tara; target: es5, module: amd/umd/systemjs/none, moduleResolution: node/node10 veya baseUrl kullanan hiçbir yapılandırma kalmasın.
2. API bağımlılıklarını belirle. typescript-eslint, ts-jest, ts-morph veya derleyicinin Program/LanguageService nesnelerine doğrudan erişen özel script'lerin var mı, kontrol et.
3. Bağımlılık yoksa doğrudan geç. npm install -D typescript@npm:@typescript/typescript6 gerekmeden typescript@^7.0.2'yi kur, tsconfig.json'daki yeni varsayılanlara göre strict/module/types alanlarını gözden geçir.
4. Bağımlılık varsa köprüle. @typescript/typescript6 paketini typescript alias'ı olarak, native derleyiciyi @typescript/native alias'ı olarak ekle; build script'lerini hangi komutun hangi çalıştırılabiliri çağırdığını netleştirecek şekilde güncelle.
5. CI'ı böl. Build adımını native tsc ile, tip kontrolünü (API'ye ihtiyaç duyan araçlar için) tsc6 ile ayrı adımlarda çalıştır; bu sayede hız kazancını kaybetmeden eski araç zincirini de canlı tutarsın.
6. 7.1'i izle. npm view typescript dist-tags ile next etiketini periyodik kontrol et; 7.1 stabil olarak yayınlandığında @typescript/typescript6 alias'ını kaldırıp doğrudan typescript@^7.1.0'a geçebilirsin.

Bu altı adımın hiçbiri geri dönüşü olmayan bir taahhüt gerektirmiyor — her adımda projenin CI'ı yeşil kalmaya devam ediyor, çünkü hız kazancı ile API bağımlılığı birbirinden ayrı katmanlarda yönetiliyor.

Karar Tablosu: Hangi Proje Bugün Geçmeli

Bütün bu bilgiyi tek bir karara indirmek için proje profiline göre bir tablo hazırladık. Buradaki mantık basit: derleyicinin programatik API'sine ihtiyaç duyan hiçbir bağımlılığın yoksa bugün geçebilirsin, varsa @typescript/typescript6 ile köprüle ya da 7.1'i bekle.

Lint katmanını TypeScript'in derleyici API'sine bağımlı olmayan bir araca (ESLint vs Biome karşılaştırmamızda ele aldığımız gibi Biome kendi ayrıştırıcısını kullanıyor) taşımış projeler için bu geçiş engeli zaten büyük ölçüde ortadan kalkıyor. Derleyici mimarisini kökten değiştirip ekosistemin yeni çekirdeğe uyum sağlamasını bekleten benzer bir geçiş sürecini Kotlin 2.1 K2 derleyicisi yazımızda da inceledik.

SSS

TypeScript 7'ye şimdi geçmeli miyim?

Eğer projen typescript-eslint, ts-jest, ts-morph gibi TypeScript'in programatik API'sine bağımlı araçlar kullanmıyorsa ve yalnızca tsc ile derleme yapıyorsa evet — TypeScript 7.0 genel kullanıma açık ve Microsoft'un kendi ekipleri dahil birçok büyük ekip gerçek kod tabanlarında test etti. Ama ESLint/derleyici API'sine bağımlı araçlara güveniyorsan, 7.1'in API'si gelene kadar @typescript/typescript6 uyumluluk paketiyle yan yana çalıştırman gerekiyor. Kararı tek bir kişisel tercihe indirmek gerekirse: ben genelde önce küçük, bağımsız bir servis paketinde deneyip CI süresindeki kazancı gözlemlemeyi, ardından ana monorepo'ya yaymayı tercih ederim — büyük bir kod tabanını tek seferde geçirmek yerine kademeli ilerlemek riski azaltıyor.

TypeScript 7 neden API ile gelmiyor, hangi araçlar kırılıyor?

Go'ya yeniden yazılan derleyici, eski JavaScript tabanlı programatik API'yi bu ilk sürümde içermiyor — Microsoft resmi olarak "TypeScript 7.0 does not ship with an API" diyor ve farklı bir API'nin 7.1'de geleceğini duyurdu. Bu yüzden typescript-eslint gibi derleyicinin JavaScript API'sine doğrudan erişen araçlar şu an TypeScript 7 üzerinde çalışamıyor.

TypeScript 6 ve 7 aynı projede birlikte çalıştırılabilir mi?

Evet. Microsoft'un yayınladığı @typescript/typescript6 paketi TS 6.0 API'sini yeniden dışa aktarıyor ve tsc6 adlı ayrı bir çalıştırılabilir dosya sağlıyor; npm alias'larıyla hem tsc (TS 7 hızı) hem de eski API'ye ihtiyaç duyan araçlar aynı projede bir arada tutulabiliyor.

TypeScript 7'de strict ve ESNext varsayılan olması neyi bozar?

Burada önemli bir ayrım var: strict: true varsayılanı aslında TypeScript 6.0 ile geldi, TypeScript 7.0 bu varsayılanı 6.0'dan devralıyor; kendi eklediği sertlik ise 6.0'da kullanımdan kaldırılmış ayarları (ör. target: es5) sert derleme hatasına çevirmesi. strict: false olarak açıkça belirtilmemiş projeler yükseltmede yeni tip hatalarıyla karşılaşabilir.

`@typescript/typescript6` paketini kurduktan sonra hangi komutu kullanmalıyım?

Ayrım net: tsc native TypeScript 7.0 derleyicisini çağırır, tsc6 ise @typescript/typescript6 paketinin sağladığı TypeScript 6.0 uyumlu çalıştırılabilirdir. Derleyici API'sine ihtiyaç duyan araçlarını (typescript-eslint gibi) tsc6'nın API'sine yönlendir, build script'lerinde hız için tsc'yi kullanmaya devam et. package.json'daki scripts alanına "build": "tsc" ve "typecheck:legacy": "tsc6 --noEmit" gibi iki ayrı komut tanımlamak, hangi komutun hangi derleyiciyi çağırdığını takım arkadaşların için de netleştirir.

7.1 çıktığında geçiş nasıl tamamlanır?

7.1'in yeni API'si stabil olarak yayınlandığında, geçiş tek yönlü ve basit: @typescript/typescript6 alias'ını package.json'dan kaldırıp typescript'i doğrudan npm:typescript@^7.1.0'a çevirmen yeterli. typescript-eslint gibi araçların 7.1 API'sine uyum sağlaması için ayrı bir sürüm yükseltmesi gerekebilir — bu yüzden 7.1 duyurusundan sonra önce bu araçların değişiklik günlüklerini kontrol etmek, ardından alias'ı kaldırmak daha güvenli bir sıralama.

Güncelleme (Eylül 2026)

Bu yazı 17 Temmuz 2026'da yayınlandı; o tarihten bugüne (5 Eylül 2026) teknik tablo değişmedi ama iki somut gelişme var:

• npm dağıtım etiketleri ve 7.1 takvimi: registry.npmjs.org üzerinde latest etiketi hâlâ 7.0.2, next etiketi ise 7.1.0-dev.20260905.1 — yani 7.1 hâlâ geliştirme sürümünde. Ama stabil sürüm için resmi bir takvim var: TypeScript ekibinin 31 Temmuz 2026'da yayımladığı 7.1 Iteration Plan tablosuna göre 6 Ekim 2026'da Beta, 10 Kasım 2026'da RC ve 24 Kasım 2026'da 7.1 Stable sürümü planlanıyor. Yani "7.1'i mi bekleyeyim" sorusunun cevabı artık belirsiz bir tarih değil; planlanan API stabilizasyonu bu takvime bağlı.
• Next.js'te useTypeScriptCli varsayılana alındı: Bayrak 10 Temmuz'da opt-in inmişti (PR #95639); 3 Ağustos'ta PR #96497 ile varsayılan oldu. Next.js dokümantasyonuna göre next build, tip kontrolü için projedeki tsc komutunu çağırıyor — "By default, next build runs the project-local tsc command instead of loading the TypeScript JavaScript compiler API. This supports TypeScript 6 and enables TypeScript 7 while its JavaScript API is unavailable." Bu, yukarıdaki "build ile tip kontrolünü ayır" önerimizin framework seviyesinde karşılığı; TypeScript 7 kullanırken ayarı kapatırsan dokümana göre "next build exits because the TypeScript JavaScript compiler API is unavailable." Yine de dokümanın kendi uyarısı geçerli: "This feature is currently experimental and subject to change, it's not recommended for production."

Sonuç

TypeScript 7 geçiş breaking change tablosu aslında göründüğünden daha basit bir karara indirgeniyor: derleyicinin programatik API'sine ihtiyacın yoksa bugün geç, varsa @typescript/typescript6 ile köprüle ya da 7.1'i bekle. Varsayılan değişiklikleri (strict, module, types, rootDir) ve kaldırılan hedefleri (es5, amd/umd/systemjs, node/node10, baseUrl) kontrol etmeden yükseltme yapma.

En önemli çıkarım şu: 11,9x'e varan hız kazancı gerçek ve ölçülmüş, ama bu kazancı "bedava" sanıp tsconfig'ini ve bağımlılık zincirini kontrol etmeden yükseltmek, CI'ını yeşilden kırmızıya çevirebilir. Geçişi bir anahtar çevirme işlemi değil, yukarıdaki altı adımlık kontrol listesini takip eden küçük bir mühendislik projesi olarak ele almak, hem hız kazancını bugün almanı hem de ekibinin araç zincirini bozmamanı sağlar.

Lint katmanını derleyici API'sinden bağımsızlaştırmak istiyorsan ESLint vs Biome karşılaştırmamıza, TypeScript'in TS 6 uyumluluk paketini modern bir edge runtime'la birlikte kullanmayı merak ediyorsan Supabase Edge Functions ile Deno runtime yazımıza, ORM katmanında da benzer bir tip-güvenliği disiplinini görmek istersen Drizzle ORM ve Turso SQLite yazımıza bakabilirsin. Büyük bir derleyici geçişini test altyapısında nasıl yönettiğimizi merak ediyorsan Swift Testing'e geçiş deneyimimiz de benzer bir "yan yana çalıştır, sonra tamamen geç" stratejisini anlatıyor. Production build hattını sıfırdan kurarken bu tür ayrımları nasıl yönettiğimizi görmek istersen Expo 52 EAS Build production rehberi de faydalı bir referans.

Kaynaklar

• TypeScript 7.0 resmi duyurusu — GA tarihi, hız tabloları, API eksikliği ve @typescript/typescript6 uyumluluk paketi birincil kaynak
• npm typescript dist-tags (canlı sorgu) — latest/next sürüm etiketlerinin gerçek zamanlı durumu
• TypeScript 7.1 Iteration Plan (microsoft/TypeScript#63703) — Beta/RC/Stable tarihlerini ve API stabilizasyonu hedefini içeren resmi takvim
• microsoft/typescript-go GitHub deposu — native port'un geliştirme deposu ve tsgo→tsc komut geçişinin resmi kaydı
• typescript-eslint Issue #12518 — aynı gün "duplicate" etiketiyle kapatılan (GitHub kapanış nedeni: not planned) kayıt; ERESOLVE, Cjs çökmesi ve maintainer gerekçesi burada
• TypeScript 6.0 sürüm notları — strict: true varsayılanının aslında 6.0'da geldiğinin resmi kaydı
• Next.js useTypeScriptCli dokümantasyonu — build sırasında tsc çağırma davranışının resmi açıklaması
• loke.dev: TypeScript 7 + typescript-eslint yan yana kullanım — 2 Ağustos 2026'da yayımlanan, doğrulanmış paket sürümleriyle pratik kurulum örneği