TypeScript 7 ve oxc: Go derleyici ve Rust linter'a geçiş rehberi

JavaScript ve TypeScript araç zincirinde son dönemde önemli bir değişim var. TypeScript compiler artık Go ile yazılmış native bir sürüm olarak ilerliyor. Oxc tarafında ise linting ve formatlama gibi araçlar Rust ile yeniden yazılıyor.

Bunları birkaç projede denedim. Hız farkı gerçekten var ama bence asıl mesele benchmarklarda görünen rakamlar değil. Tip kontrolü, lint ve formatlama yeterince hızlı olduğunda geliştirme akışı değişiyor. Daha önce beklediğin için atladığın kontrolleri artık sürekli çalıştırabiliyorsun.

Öte yandan her araç aynı olgunlukta değil. Oxlint'i mevcut ESLint kurulumunun yanına koymak oldukça düşük riskli. TypeScript 7'ye geçmek ise compiler API kullanan araçlar yüzünden daha dikkatli yapılması gereken bir iş. Oxfmt de henüz beta olduğu için ayrı değerlendirilmeli. Aşağıda kendi geçişlerimde karşılaştığım noktaları ve bugün nasıl ilerleyeceğimi anlatıyorum.

TypeScript 7

TypeScript 7, 8 Temmuz 2026'da yayımlandı. Bu sürümün en büyük değişikliği dilin kendisinde değil, compiler'ın uygulanmasında. TypeScript 7 ile compiler native bir Go uygulaması olarak geliyor. Amaç yeni bir TypeScript dili tasarlamak değil; mevcut compiler'ın davranışını mümkün olduğunca koruyarak performansını ciddi biçimde artırmak.

Microsoft'un yayınladığı benchmarklarda büyük projelerde tip kontrolü ve build sürelerinde çok ciddi düşüşler görülüyor. VS Code deposunda tam tip kontrolü için örneğin yaklaşık 125 saniyeden 10 saniye civarına inen ölçümler var. Bu rakamları doğrudan kendi projenize uygulamamak gerekiyor. Gerçek bir projede disk erişimi, process başlatma maliyeti, cache durumu, kullanılan CPU ve monorepo'nun yapısı sonucu ciddi biçimde etkiliyor. Yine de temel sonuç değişmiyor: büyük TypeScript projelerinde compiler artık çok daha hızlı.

Neden Go?

İlk bakışta "neden Rust değil?" sorusu oldukça doğal. TypeScript compiler'ın mevcut kodu birbirine referans veren karmaşık veri yapıları ve grafikler üzerinde çalışıyor. Rust'ın sahiplik modeli böyle bir yapının doğrudan taşınmasını zorlaştırıyor. Rust ile yapılacak bir port, mevcut compiler'ın önemli bölümlerinin yeniden tasarlanmasını gerektirebilirdi. Go ise garbage collector'a sahip, native binary üretiyor ve bu tür döngüsel veri yapılarıyla çalışmak daha kolay.

Buradaki önemli nokta şu: Go'nun seçilmesinin temel nedeni "Rust'tan daha hızlı" olması değil. TypeScript ekibinin önceliği mevcut compiler'ın yapısını ve davranışını mümkün olduğunca koruyarak native bir uygulamaya geçmekti. Go, bu hedef için daha düşük bir yeniden yazım maliyeti sundu.

Yani TypeScript 7'deki performans artışını sadece "Go hızlı" diye açıklamak eksik kalıyor. Native çalışma, veri yapılarının düzenlenmesi ve compiler'ın paralel çalışabilmesi birlikte sonucu oluşturuyor.

Paralel tip kontrolü

Performans tarafındaki önemli değişikliklerden biri de paralel çalışma. Tip kontrolü için birden fazla checker kullanılabiliyor, project reference build'leri de paralel çalıştırılabiliyor:

tsc --checkers 4 --builders 4
tsc --singleThreaded

Daha fazla worker her zaman daha hızlı demek değil. CPU kadar bellek de önemli. Özellikle CI makinelerinde checker sayısını artırdığında bellek kullanımının da arttığını hesaba katmak gerekiyor. Ben bunu doğrudan 8 checker daha hızlıdır şeklinde ayarlamazdım, önce gerçek CI makinesinde ölçerdim.

Editör tarafı

TypeScript 7'nin günlük kullanımda en çok hissedilecek tarafı editör. Büyük bir TypeScript projesinde dosyayı kaydettikten sonra tip hatalarının güncellenmesini beklemek gerçek bir geliştirme maliyetiydi. Native compiler ve paralel çalışma sayesinde bu bekleme ciddi biçimde azalıyor.

Burada compiler ile language server'ı birbirine karıştırmamak gerekiyor. tsc'nin hızlanması editördeki her özelliğin otomatik olarak aynı oranda hızlandığı anlamına gelmiyor. VS Code ve diğer editör entegrasyonları kendi sürümlerine ve TypeScript API'lerine bağlı. Bu nedenle tsc --noEmit çalıştırıp işi bitmiş saymamak, editörü ve build zincirini de ayrıca kontrol etmek gerekiyor.

Denemek için

Mevcut projede ilk adım basit:

npm install -D typescript@7
npx tsc --version
npx tsc --noEmit

--noEmit ile başlamak mantıklı. Böylece build çıktısını değiştirmeden yeni compiler'ın projedeki tip kontrolünü görebiliyorsun.

Eski bir projeyi doğrudan TypeScript 5'ten 7'ye geçirmek yerine önce TypeScript 6'ya geçirmek de daha güvenli. TypeScript 6'da deprecated edilen seçenekler 7'de kaldırılmış durumda. Bu ara geçiş özellikle eski projelerde hangi hatanın gerçekten TypeScript 7'den kaynaklandığını anlamayı kolaylaştırıyor.

Asıl geçiş sorunu: compiler API

TypeScript 7'de benim için hızdan daha önemli konu compiler API. Birçok araç TypeScript'i yalnızca komut satırından çalıştırmıyor, doğrudan compiler API'ye bağlanıyor:

import * as ts from "typescript"

Bu araçlar AST oluşturabiliyor, AST üzerinde değişiklik yapabiliyor, type checker'a sorular sorabiliyor veya compiler'ın iç yapısına dayanabiliyor. typescript-eslint, ts-morph, custom transformer'lar ve çeşitli framework'lerin template type-checker'ları bu nedenle TypeScript sürümünden daha fazla etkileniyor.

TypeScript 7.0 ile eski compiler API'nin doğrudan ve kararlı bir karşılığı gelmiş değil, yeni API üzerinde çalışma devam ediyor. Bu nedenle compiler API kullanan bir araç için "TypeScript 7 çıktı, sürümü yükselt ve devam et" yaklaşımı doğru değil. Önce kullandığın aracın TypeScript 7 desteğine bakmak gerekiyor. Özellikle şunları kontrol etmek lazım:

typescript-eslint
ts-morph
custom transformer'lar
code generation araçları
Vue, Svelte, Astro, Angular ve MDX tooling'i
şirket içinde yazılmış TypeScript compiler araçları

Bir araç TypeScript 7 ile henüz çalışmıyorsa bütün projeyi geri çevirmek yerine, geçici olarak o aracın ihtiyaç duyduğu eski TypeScript sürümünü ayrı tutmak daha mantıklı olabilir. Burada package.json'a rastgele iki TypeScript sürümü eklemek yerine kullandığın aracın önerdiği geçiş yöntemini izlemek gerekiyor.

Oxc

Oxc, Rust ile yazılmış JavaScript ve TypeScript araçlarından oluşan bir proje. Tek bir araç değil, birbirinin üstüne binen bir parçalar topluluğu:

flowchart TD
    parser["parser"] --> linter["oxlint"]
    parser --> formatter["oxfmt"]
    parser --> transformer["transformer"]
    parser --> minifier["minifier"]
    resolver["resolver"] --> linter
    resolver --> transformer
    linter -.->|tip bilgisi| tsgolint["tsgolint"]

Parser kaynak kodu AST'ye çeviriyor, resolver modülleri çözüyor, transformer TypeScript ve JSX dönüşümlerini yapıyor, minifier üretim çıktısını küçültüyor. Linter ile formatlayıcı da aynı AST'nin üstünde çalışıyor, yani aynı dosya her araç için baştan ayrıştırılmıyor. Tip bilgisi isteyen bir kural olduğunda oxlint tsgolint'e uğruyor, onu az sonra anlatacağım. Rolldown da bu altyapının üstünde duruyor. Bu yazıda iki parça önemli: linter tarafında oxlint, formatter tarafında oxfmt.

Bunların olgunluk seviyeleri aynı değil. Oxlint bugün daha hazır bir araç, Oxfmt ise hâlâ beta. Bu yüzden ikisine aynı geçiş stratejisini uygulamıyorum.

ESLint'ten Oxlint'e

Oxlint'in en güçlü tarafı hız. Kurulum basit:

pnpm add -D oxlint
pnpm oxlint
pnpm oxlint --fix

Mevcut ESLint yapılandırmasını taşımak için migration aracı da kullanılabiliyor:

npx @oxlint/migrate

Ama ben ESLint'i ilk gün kaldırmam. Önce ikisini birlikte çalıştırırım:

{
  "scripts": {
    "lint": "oxlint && eslint ."
  }
}

Bir süre iki çıktıyı karşılaştırmak, hangi ESLint kurallarının Oxlint tarafından karşılandığını görmek için çok daha güvenli. Sonraki adımda eslint-plugin-oxlint ile Oxlint'in zaten kontrol ettiği kuralları ESLint tarafında kapatabilirsin. Böylece yapı kabaca şöyle olur:

flowchart LR
    kod([kaynak kod]) --> oxlint["oxlint"]
    kod --> eslint["ESLint"]
    oxlint --> sonuc([lint sonucu])
    eslint --> sonuc

Oxlint desteklediği kuralları hızlıca geçiyor, ESLint ise yalnızca Oxlint'te karşılığı olmayanlara bakıyor.

Bu geçiş biçiminin avantajı ESLint'i bir anda ortadan kaldırmamak. Özel ESLint plugin'lerin veya şirket içinde yazılmış kuralların varsa onları kullanmaya devam edebilirsin. Oxlint'in kapsaması genişlediği için zaman içinde ESLint'in tuttuğun kısmı da küçülebilir.

Oxlint yapılandırması

Basit bir yapılandırma şöyle olabilir:

{
  "$schema": "./node_modules/oxlint/configuration_schema.json",
  "categories": {
    "correctness": "error",
    "suspicious": "warn",
    "pedantic": "off"
  },
  "rules": {
    "no-console": "warn",
    "typescript/no-explicit-any": "error"
  },
  "ignorePatterns": [
    "dist",
    "build",
    "**/*.generated.ts"
  ],
  "overrides": [
    {
      "files": [
        "**/*.test.ts",
        "**/*.spec.ts"
      ],
      "rules": {
        "no-console": "off",
        "typescript/no-non-null-assertion": "off"
      }
    }
  ]
}

Bütün kuralları tek tek yazmak gerekmiyor. Önce kategorileri kullanıp gerçekten farklı davranmasını istediğin kuralları ayrıca tanımlamak daha rahat. Migration aracını çalıştırdıktan sonra üretilen yapılandırmayı da mutlaka gözden geçirmek gerekiyor. Özellikle ESLint plugin'lerinin birebir karşılığı olmayan kurallar sessizce kaybolmamalı.

Tip bilen linting

Oxlint'in ilk dönemlerindeki önemli eksiklerden biri tip bilgisi isteyen kurallardı. Örneğin:

async function saveUser(user: User): Promise<void> {
  await db.users.update(user)
}

async function handler(req: Request) {
  saveUser(req.user)
  return new Response("ok")
}

Buradaki sorun sözdizimsel değil. saveUser() bir Promise döndürüyor ve çağıran taraf onu beklemiyor. Bunu anlayabilmek için linter'ın saveUser fonksiyonunun dönüş tipini bilmesi gerekiyor. İşte burada type-aware linting devreye giriyor.

Oxc tarafında bu iş için TypeScript'in Go tabanlı compiler altyapısından yararlanan tsgolint kullanılıyor. Mimari kabaca şöyle:

flowchart LR
    subgraph rust["Rust tarafı"]
        oxlint["oxlint"] --> kurallar["normal lint kuralları"]
    end
    subgraph go["Go tarafı"]
        tsgolint["tsgolint"] --> ts7["TypeScript 7<br/>program ve tip bilgisi"]
    end
    oxlint -->|tip gerektiren kural| tsgolint

Dolayısıyla "Oxlint TypeScript'in tip sistemini Rust'ta yeniden yazdı" demek doğru değil. Rust tarafı linting işini yapıyor, tip bilgisi gerektiğinde TypeScript compiler altyapısından yararlanılıyor.

Kurulum ve kullanım kullandığın Oxc sürümüne göre değişebileceği için güncel dokümantasyondaki paket adlarını kontrol etmek gerekiyor. Type-aware linting'i açtığında temel fikir ise aynı:

pnpm oxlint --type-aware

TypeScript compiler diagnostics'lerini de aynı çalıştırmaya dahil etmek istiyorsan typeCheck seçeneği ayrıca kullanılabiliyor. Bu iki kavramı ayırmak önemli:

typeAware: tip bilgisine ihtiyaç duyan lint kurallarını çalıştırır.
typeCheck: TypeScript compiler diagnostics'lerini de kontrol eder.

Tip bilen kurallar neden önemli?

Örneğin:

function greet(name: string) {
  if (name !== undefined) {
    // ...
  }
}

name zaten string olduğu için bu koşul gereksiz. Başka bir örnek:

const limit = input.limit || 20

limit sıfır olabiliyorsa burada || istenmeyen bir davranış üretebilir. input.limit ?? 20 ise yalnızca null veya undefined durumunda varsayılan değeri kullanır.

Bunlar yalnızca AST'ye bakarak güvenilir biçimde çözülebilecek problemler değil, linter'ın tip sistemini bilmesi gerekiyor. Bu yüzden type-aware linting normal linting'den ayrı bir maliyet sınıfı.

Performans rakamlarını nasıl okumalı?

Oxc tarafında yayınlanan benchmarklarda tsgolint'in typescript-eslint'in type-aware linting çalışmasına göre ciddi hız avantajı gösterdiği ölçümler var:

Depo	ESLint + typescript-eslint	tsgolint
microsoft/vscode	83,2 sn	6,96 sn
microsoft/typescript	27,2 sn	1,94 sn
typeorm/typeorm	13,2 sn	0,75 sn
vuejs/core	12,3 sn	0,95 sn

Bunlar proje ve benchmark koşullarına bağlı ölçümler, kendi CI'ında aynı süreleri göreceğin anlamına gelmiyor. Özellikle iki şeyi ayırmak gerekiyor. Normal Oxlint ile type-aware Oxlint aynı benchmark değil. Ayrıca TypeScript programının oluşturulması, dosyaların okunması ve config çözümlemesi gibi maliyetler küçük projelerde toplam sürenin daha büyük kısmını oluşturabiliyor. Bu yüzden "18 kat hızlı" gibi bir rakamı doğrudan kendi projenin sonucuna çevirmem. Asıl önemli olan kendi CI süren.

Type-aware linting ve tsconfig

Tip bilen linting açıldığında TypeScript programının nasıl oluşturulduğu önem kazanıyor. Monorepo'da include ve exclude desenleri gereğinden genişse lint süresi büyüyebilir. Generated dosyaları, build çıktıları veya test fixture'larını yanlışlıkla TypeScript programına dahil etmek de gereksiz maliyet yaratabilir.

Bir başka sorun da package reference'ları. Bir paket diğerinin oluşturduğu .d.ts dosyalarına dayanıyorsa ve bu çıktılar henüz oluşturulmamışsa type-aware linting beklediğin kadar kapsamlı çalışmayabilir. Bu nedenle type-aware linting'i açmadan önce mevcut TypeScript proje yapısının düzgün olduğundan emin olmak gerekiyor.

Oxfmt

Oxfmt, Oxc projesinin Rust tabanlı formatlayıcısı ve şu anda beta. Hedefi Prettier ile yüksek uyumluluk sağlarken formatlama işlemini çok daha hızlı yapmak. Oxc'nin kendi benchmarklarında Oxfmt'nin Prettier'dan ve Biome'dan ciddi biçimde hızlı olduğu görülüyor. Ancak benchmark sonuçlarını üretim ortamındaki bütün formatlama işlemlerinin aynı oranda hızlanacağı şeklinde yorumlamamak gerekiyor.

Oxfmt'nin ilginç tarafı yalnızca hız değil. JavaScript ve TypeScript'in yanında JSON, YAML, TOML, HTML, Vue, CSS, Markdown, GraphQL gibi formatları da destekliyor. Import sıralama ve Tailwind class sıralama gibi bazı işlemleri de formatlama akışına dahil edebiliyor.

Ama burada Oxlint'ten daha temkinliyim. Formatlayıcı bütün dosyaya dokunuyor. Linter'daki yanlış bir kural birkaç satır gösterebilir, formatlayıcı ise yüzlerce dosyada büyük diff oluşturabilir. Bu nedenle beta bir formatter'a geçerken bütün repoyu tek commit'te yeniden formatlamazdım. Önce ayrı bir branch'te dener, diff'i inceler ve ekipteki diğer araçlarla uyumunu kontrol ederdim.

Prettier'dan hemen çıkmak gerekir mi?

Bence hayır. Oxfmt bugün denemek için yeterince ilginç, performans tarafındaki fark da ciddi. Ama formatter'ın stabilitesi hızından daha önemli.

Özellikle büyük bir repoda formatter değişikliği yalnızca teknik bir değişiklik değil, Git geçmişini de etkiliyor. Bütün dosyaları yeniden formatladığında gerçek kod değişikliklerini görmek zorlaşıyor. Bu nedenle sıralamayı şöyle kuruyorum:

oxlint: bugün rahatça denenebilir.
TypeScript 7: araç zinciri kontrol edilerek geçilmeli.
oxfmt: beta olduğu için ölçerek denenmeli.

CI ve pre-commit

Bu araçların gerçek faydası CI'da ortaya çıkıyor:

jobs:
  static:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: pnpm/action-setup@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: pnpm

      - run: pnpm install --frozen-lockfile

      - run: pnpm oxlint --type-aware

      - run: pnpm tsc --noEmit

      - run: pnpm oxfmt --check

Lint, type-check ve format kontrolünü ayrı adımlarda tutmayı tercih ediyorum. Sebebi yalnızca performans değil; CI kırıldığında hangi kontrolün kırıldığını doğrudan görebiliyorsun. Kod tabanı büyüdüğünde bunları ayrı job'lara da bölebilirsin, o zaman lint ve type-check paralel çalışabilir. Ama küçük bir projede sırf teorik olarak paralel çalıştırmak için karmaşık bir CI yapısı kurmanın pek anlamı yok.

Pre-commit tarafında daha seçici davranıyorum:

{
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": [
      "oxlint --fix",
      "prettier --write"
    ],
    "*.{json,css,md,yaml}": "prettier --write"
  }
}

Type-aware linting'i burada çalıştırmak istemiyorum. Tek bir dosya değişmiş olsa bile TypeScript programının oluşturulması gerekebilir ve büyük projelerde bunun commit başına maliyeti gereksiz olabilir. Pre-commit'te hızlı ve dosya odaklı kontrolleri çalıştırıp daha ağır analizleri CI'a bırakmak daha mantıklı.

Oxfmt'ye geçtiğinde formatlama satırını prettier --write yerine oxfmt olarak değiştirebilirsin. Ama bunu Oxfmt'nin proje için yeterince stabil olduğuna karar verdikten sonra yapardım.

Kendi ölçümlerim

Birkaç projede bu geçişleri yaptım. Resmi benchmarklarda görülen 10-20 katlık sonuçları her projede görmedim. Bu şaşırtıcı değil. Gerçek projede yalnızca linter çalışmıyor: dosyalar bulunuyor, config dosyaları okunuyor, Node process'i başlıyor, Git hook'ları çalışıyor ve bazen aynı makinede başka işler de yapılıyor. Bunların bir kısmı araç değiştiğinde aynı kalıyor. Bu nedenle resmi benchmarkta 15 kat görünen fark gerçek projede 4-5 kata düşebiliyor.

Ama 20 saniyelik bir kontrolün 4 saniyeye düşmesi bile günlük kullanımda büyük fark, çünkü insan davranışını değiştiriyor. 20 saniye beklemek istemeyen geliştirici hook'u git commit --no-verify ile atlayabilir. 4 saniye ise çoğu zaman beklenebilir bir süre. Bence hızlı araçların gerçek değeri burada. Benchmarkta yazan sayıdan daha önemli olan şey, aracın artık geliştirme akışını kesmemesi.

Nasıl bir sırayla geçerdim

Bütün araç zincirini aynı gün değiştirmezdim. TypeScript 7 tarafında önce TypeScript 6'daki deprecation'ları temizlerdim. Sonra TypeScript 7'yi CI'da tsc --noEmit ile tip kontrolü için çalıştırırdım. Ardından editör ve build araçlarını kontrol eder, en son compiler API kullanan araçlara bakardım. Bir araç TypeScript 7'yi desteklemiyorsa o aracın güncellenmesini beklemek veya geçici bir uyumluluk çözümü kullanmak daha mantıklı. Burada önemli olan bütün araçların aynı gün TypeScript 7'ye geçirilmesi değil; asıl hedef, compiler'ı güncellerken build zincirini parça parça doğrulamak.

Oxlint tarafında daha rahatım. Önce pnpm add -D oxlint ile kurup CI'a eklerim, ESLint'i kaldırmam. Bir süre oxlint && eslint şeklinde çalıştırırım. Sonra Oxlint'in zaten kontrol ettiği kuralları ESLint'ten çıkarır, daha sonra type-aware linting'i açarım. En sonunda ESLint'te hâlâ ihtiyacım olan plugin ve kuralları belirlerim. Böylece geçiş tek seferlik büyük bir değişiklik olmaktan çıkıyor.

Her şeyi değiştirmek zorunda değilsin

TypeScript 7'nin çıkması mevcut bütün projeleri hemen güncellemen gerektiği anlamına gelmiyor. Aynı şey Oxlint ve Oxfmt için de geçerli.

Yeni bir proje başlatıyorsam TypeScript 7 ve Oxlint benim için oldukça mantıklı bir başlangıç. Oxfmt'yi ise projenin büyüklüğüne ve formatter'ın beta durumuna göre değerlendiririm. Mevcut büyük bir projede ise daha yavaş ilerlerim:

flowchart TD
    a1["TypeScript 6"] --> a2["deprecation temizliği"]
    a2 --> a3["CI'da TypeScript 7"]
    a3 --> a4["editör ve build kontrolü"]
    a4 --> a5["TypeScript 7"]

    b1["ESLint"] --> b2["oxlint'i yanına ekle"]
    b2 --> b3["örtüşenleri kapat"]
    b3 --> b4["type-aware linting"]
    b4 --> b5["ESLint'i azalt"]

Soldaki sütun derleyici tarafı, sağdaki lint tarafı. İkisi birbirini beklemeden paralel yürüyebiliyor.

Bu yaklaşımın en büyük avantajı, bir şey bozulduğunda hangi değişikliğin bozduğunu bilmen.

Sonuç

JavaScript ve TypeScript ekosistemindeki araç zinciri ciddi biçimde değişiyor. TypeScript compiler Go'ya taşındı, Oxlint Rust ile yazılıyor, tip bilen linting TypeScript 7'nin compiler altyapısından yararlanıyor. Oxfmt ise Rust tabanlı bir formatter olarak Prettier'a alternatif olmaya çalışıyor.

Bunlar aslında birbirinin rakibi değil, aynı araç zincirinin farklı parçaları. TypeScript 7 compiler ve tip kontrolünü, Oxlint linting'i, tsgolint tip bilen linting'i, Oxfmt de formatlamayı üstleniyor. Buradaki asıl değişiklik "Rust daha hızlı" veya "Go daha hızlı" meselesinden biraz daha büyük.

Yazı boyunca anlatılanların kısa hâli:

Durum	İlk adım	Alternatif ve notlar
Mevcut projede lint hızlandırmak	oxlint'i ESLint'in yanına ekle	ESLint'i bırakma, `eslint-plugin-oxlint` ile örtüşenleri kapat
`no-floating-promises` gibi kurallar lazım	`oxlint --type-aware`	typescript-eslint (yavaş ama yerleşik), tsconfig'i önce toparla
TypeScript 5'ten yükseltme	Önce TypeScript 6, sonra 7	Doğrudan 7'ye atlarsan hataların kaynağı karışır
Compiler API kullanan araç var	Aracın TypeScript 7 desteğini bekle	Aracın önerdiği uyumluluk yöntemi, geçici sürüm ayrımı
Formatlayıcıyı değiştirmek	Prettier'da kal	oxfmt'yi ayrı branch'te dene, diff'i incele
Yeni proje kuruyorsun	TypeScript 7 + oxlint	oxfmt'yi beta durumuna göre değerlendir
CI süresi uzun	Lint, tip kontrolü ve formatı ayrı adımlara böl	Büyük repoda ayrı job, küçük projede gereksiz

TypeScript 7 ve Oxc: geçiş notları