TypeScript 7.0 duyuruldu

 (devblogs.microsoft.com)
4 puan yazan GN⁺ 2 시간 전 | 2 yorum | WhatsApp'ta paylaş
  • TypeScript 7.0, araç zincirinin Go tabanlı yerel koda taşındığı bir sürüm; büyük projelerin tam derlemelerinde genellikle 8~12 kat hız artışı sağlıyor
  • Yeni tsc, eskisi gibi npm’deki typescript paketiyle kuruluyor; editör desteği ise LSP tabanlı dil sunucusu üzerinden VS Code, Visual Studio, WebStorm gibi ortamlarda çalışıyor
  • vscode, sentry, bluesky, playwright, tldraw gibi kod tabanlarında derleme süreleri ciddi ölçüde azaldı; bazı ortamlarda toplam bellek kullanımı da düştü
  • TypeScript 7.0’da henüz kararlı bir programlama API’si bulunmadığından typescript-eslint, Vue, MDX, Astro, Svelte, Angular şablon tip denetimi gibi TypeScript’i içine gömen araçların TypeScript 6.0 ile birlikte kullanımı gerekiyor
  • Yeni varsayılanlar ve kaldırılmış seçenekler bulunduğu için, geçiş açısından önce TypeScript 6.0 değişikliklerini uygulamak avantajlı; TypeScript 7.1 ile yeni API’nin sunulması planlanıyor

Go tabanlı yerel TypeScript

  • TypeScript 7.0, TypeScript araç zincirinin yerel portu olup Go ile yazılmış yeni bir kod tabanı kullanıyor
  • Mevcut kod tabanının yapısı ve mantığı mümkün olduğunca korunarak, iki derleyici arasındaki sonuçların tutarlılığı ve uyumluluğu sağlanacak şekilde port edildi
  • Yeni kod tabanı; yerel kod hızı, paylaşımlı bellek tabanlı çok iş parçacıklılık ve çeşitli optimizasyonlar sayesinde tam derlemelerde genellikle 8~12 kat daha hızlı sonuç veriyor
  • Kurulum, eskisi gibi npm ile yapılabiliyor
npm install -D typescript
  • Kurulumdan sonra çalışma alanında yeni tsc çalıştırılabilir dosyası kullanılabilir; npx tsc ile çalıştırılabilir

Geliştirme geri bildirim döngüsünün kısalması

  • TypeScript; editörün yüklenmesi, tüm referansları bulma, otomatik tamamlama, tanılama, tsc, --watch modu gibi geliştirme sürecinin birçok aşamasında yer alır
  • TypeScript 7, bu sürecin genelindeki bekleme süresini azaltarak geri bildirim döngüsünü kısaltır
  • VS Code kod tabanında hata içeren bir dosya açıldığında ilk hatanın görünmesine kadar geçen süre yaklaşık 17,5 saniyeden 1,3 saniyenin altına düşerek 13 kattan fazla hızlandı
  • Editör desteği LSP tabanlıdır; yeni dil sunucusu, eşzamanlı istekleri hızlı işlemek için çok iş parçacıklılıktan yararlanır
  • VS Code kullanıcıları TypeScript 7’ye özel eklentiyi kurabilir; önümüzdeki birkaç hafta içinde VS Code’un kendisine de TypeScript 7 desteğinin dahil edilmesi planlanıyor
  • Visual Studio’nun en güncel sürümü, çalışma alanına bağlı olarak TypeScript 7’yi otomatik etkinleştirir

Derleme performansı ve bellek sonuçları

  • TypeScript 6 ve 7’nin büyük açık kaynak kod tabanlarında karşılaştırıldığı tam derleme süreleri şöyle
Kod tabanı TypeScript 6 TypeScript 7 Hız artışı
vscode 125,7 sn 10,6 sn 11,9 kat
sentry 139,8 sn 15,7 sn 8,9 kat
bluesky 24,3 sn 2,8 sn 8,7 kat
playwright 12,8 sn 1,47 sn 8,7 kat
tldraw 11,2 sn 1,46 sn 7,7 kat
  • Aynı derlemelerde TypeScript 7 genel olarak toplam bellek kullanımını da düşürdü
Kod tabanı TypeScript 6 TypeScript 7 Bellek değişimi
vscode 5,2GB 4,2GB -18%
sentry 4,9GB 4,6GB -6%
bluesky 1,8GB 1,3GB -26%
playwright 1,0GB 0,9GB -11%
tldraw 0,6GB 0,5GB -15%

Gerçek kod tabanlarında doğrulama ve ekip geri bildirimleri

  • TypeScript projesi, 10 yılı aşkın sürede birikmiş on binlerce testi her main branch commit’inde çalıştırır
  • TypeScript 7, bu testlerin yanı sıra şirket içi ve dışındaki büyük ekiplerin gerçek kod tabanlarında da doğrulandı
  • Microsoft içinde Loop, Office, PowerBI, Teams ve Xbox ekipleri TypeScript 7’yi doğruladı
  • Dışarıda ise Bloomberg, Canva, Figma, Google, Lattice, Linear, Miro, Notion, Sentry, Slack, Vanta, Vercel, VoidZero gibi ekipler kod tabanlarında test edip geri bildirim sağladı
  • Yeni dil sunucusu, TypeScript 6.0’a kıyasla başarısız dil sunucusu komutlarını %80’den fazla, sunucu çökmelerini ise %60’tan fazla azalttı
  • Gerçek ekip geri bildirimleri şu örnekleri içeriyor
    • Slack, TypeScript 7 ile merge queue süresinin %40 azaldığını ve CI tip denetimi süresinin yaklaşık 7,5 dakikadan 1,25 dakikaya düştüğünü aktardı
    • Vanta, büyük projelerinden birinde 9 kata varan derleme hızı artışı gördü
    • Microsoft News Services ekibi, CI derlemesi bekleme süresinde ayda 400 saat tasarruf etti
    • Canva, editörde ilk hatanın görünmesine kadar geçen sürenin yaklaşık 58 saniyeden 4,8 saniyeye düştüğünü aktardı

TypeScript 6.0 ile birlikte çalıştırma

  • TypeScript 7.0 henüz API içermiyor
  • TypeScript 7.1’de yeni ve farklı bir API sunulması planlanıyor
  • O zamana kadar derleyiciye programatik erişim gerektiren araçlar için TypeScript 6.0 ve 7.0 birlikte çalıştırılabilir
  • Yeni uyumluluk paketi @typescript/typescript6, tsc6 çalıştırılabilir dosyasını sağlar ve TypeScript 6.0 API’sini yeniden dışa aktarır
  • typescript-eslint gibi typescripti peer dependency olarak doğrudan import eden araçlar için npm alias kullanımı önerilir
npm install -D typescript@npm:@typescript/typescript6
  • TypeScript 6 API’si ile TypeScript 7’nin tsc’sini birlikte kullanmak için aşağıdaki gibi alias tanımlanabilir
{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}
  • Mevcut @typescript/native-preview paketi, TypeScript 7’nin yeni kod tabanının nightly derlemelerini sunuyordu ve haftalık indirme sayısı 8,5 milyonun üzerindeydi
  • Bundan sonra nightly derlemeler standart typescript paketinin next etiketiyle yeniden başlayacak
npm install -D typescript@next

Paralelleştirmeyi kontrol etme seçenekleri

  • TypeScript 7.0; ayrıştırma, tip denetimi, emit gibi birden çok aşamayı paralel çalıştırır

  • Ayrıştırma ve emit, dosya bazında bağımsız çalıştırılmaya elverişli olduğundan büyük kod tabanlarında nispeten düşük ek yükle ölçeklenir

  • Yeni deneysel bayraklar --checkers, --builders, --singleThreaded paralelleştirme davranışını ayarlar

  • --checkers

    • TypeScript 7.0 sabit sayıda tip denetimi worker’ı oluşturur ve aynı girdi dosyaları için işleri her zaman aynı şekilde bölüştürerek aynı sonuçların üretilmesini sağlar
    • Varsayılan tip denetimi worker sayısı 4 olup --checkers ile ayarlanabilir
    • Aynı makinede --checkers 8 kullanıldığında sonuçlar şöyle
    Kod tabanı TypeScript 6 TypeScript 7 --checkers 8 Hız artışı
    vscode 125,7 sn 7,51 sn 16,7 kat
    sentry 139,8 sn 12,08 sn 11,6 kat
    bluesky 24,3 sn 2,01 sn 12,1 kat
    playwright 12,8 sn 1,16 sn 11 kat
    tldraw 11,2 sn 1,06 sn 10,6 kat

  • --checkers artırıldığında daha fazla CPU çekirdeği kullanılarak build hızlanabilir, ancak genellikle bellek kullanımında artış da beraberinde gelir

    • CPU çekirdeği ve belleği az olan CI runner’larında, gereksiz ek yükten kaçınmak için değer düşürülebilir
    • --checkers 1, tip denetimini fiilen tek iş parçacıklı hale getirir ve yinelenen işleri ortadan kaldırır
    • Nadir durumlarda --checkers sayısındaki değişiklikler sıralamaya bağlı sonuçları ortaya çıkarabilir; bu nedenle build ortamı genelinde sabit bir checker sayısı belirtmek faydalı olabilir

  • --builders

    • --builders, --build çalıştırılırken aynı anda çalışabilecek proje referansı builder sayısını kontrol eder
    • Çok sayıda projesi olan monorepo’larda özellikle yardımcı olabilir
    • Değeri artırmak build’i hızlandırabilir, ancak bellek kullanımını da artırabilir
    • --checkers ile çarpan etkisi vardır; --checkers 4 --builders 4 ile aynı anda en fazla 16 tip denetleyicisi çalışabilir
    • --builders sayısındaki değişiklikler, --checkersın aksine farklı sonuçlar üretmemelidir
    • Proje referansı build’leri temel olarak projenin bağımlılık grafiği nedeniyle darboğaza girer

  • --singleThreaded

    • --singleThreaded, derleyicinin tamamının tek iş parçacıklı çalışmasını sağlar
    • Hata ayıklama, TypeScript 6 ile 7 arasında performans karşılaştırması, harici paralel build orkestrasyonu ve kaynakların çok sınırlı olduğu ortamlar için yararlı olabilir
    • Bu bayrak yalnızca tip denetimi worker sayısını 1 ile sınırlamakla kalmaz, parsing ve emit işlemlerinin de tek iş parçacığında yapılmasını sağlar

Yeni --watch modu

  • TypeScript 7, --watch modunu tamamen yeniden oluşturdu
  • Yeni --watch, Parcel bundler’ın file-watcher’ını temel alarak verimli ve güvenilir çapraz platform dosya izleme işlevi sunar
  • Go standart kütüphanesinde yerleşik bir dosya izleme API’si yok; incelenen üçüncü taraf kütüphanelerde ise kararlılık, performans, çapraz platform desteği ve build aracı entegrasyonu açısından sorunlar vardı
  • Saf polling yaklaşımı çeşitli işletim sistemlerinde çalışsa da, çok sayıda node_modules bağımlılığı olan büyük projelerde hesaplama maliyeti yüksekti
  • TypeScript ekibi, VS Code’da kullanılan @parcel/watcher paketini Go’ya port etti ve C++ toolchain bağımlılığından kaçınmak için minimum düzeyde assembly shim kullandı
  • Bu watcher bağımsız bir pakettir ve TypeScript 7’nin --watch modunda platformlar genelinde kaynak kullanımında iyileşme sağlar

TypeScript 6.0 varsayılanları ve uyumluluk değişiklikleri

  • TypeScript 7.0, TypeScript 6.0’ın tip denetimi ve komut satırı davranışıyla uyumlu olacak şekilde tasarlandı
  • stableTypeOrdering bayrağı açıkken ve ignoreDeprecations ayarlanmamışken TypeScript 6.0 ile sorunsuz derlenen kodun TypeScript 7.0’da da aynı şekilde derlenmesi gerekir
  • TypeScript 7.0, TypeScript 6.0’ın yeni varsayılanlarını benimser ve TypeScript 6.0’da deprecated olan bayraklar ile söz dizimleri için hard error üretir
  • Başlıca ayar varsayılanı değişiklikleri şunlardır
    • strict varsayılanı true
    • module varsayılanı esnext
    • target varsayılanı, esnextten hemen önceki mevcut kararlı ECMAScript sürümü
    • noUncheckedSideEffectImports varsayılanı true
    • libReplacement varsayılanı false
    • stableTypeOrdering varsayılanı true ve kapatılamaz
    • rootDir varsayılanı ./
    • types varsayılanı []; önceki davranış ["*"] ile geri getirilebilir
  • rootDir ve types değişiklikleri en şaşırtıcı olabilecek değişiklikler olarak gösteriliyor
    • tsconfig.json dosyası src gibi kaynak dizinlerinin dışında bulunan projelerde, mevcut dizin yapısını korumak için rootDir açıkça belirtilmelidir
    • Belirli global bildirimlere bağlı projelerde, gerekli @types paketleri types içinde açıkça belirtilmelidir
{
  "compilerOptions": {
    "rootDir": "./src"
  },
  "include": ["./src"]
}

{
  "compilerOptions": {
    "types": ["node", "jest"]
  }
}

Kaldırılan veya hard error haline gelen davranışlar

  • TypeScript 7.0’da TypeScript 6.0’da deprecated edilmiş çeşitli seçenekler ve söz dizimleri artık desteklenmiyor
  • Başlıca maddeler şunlardır
    • target: es5 desteklenmiyor
    • downlevelIteration desteklenmiyor
    • moduleResolution: node/node10 desteklenmiyor; nodenext ve bundler öneriliyor
    • module: amd, umd, systemjs, none desteklenmiyor; bundler veya tarayıcı tabanlı modül çözümlemesiyle birlikte esnext ya da preserve öneriliyor
    • baseUrl desteklenmiyor; paths, baseUrl yerine proje köküne göre göreli yollarla güncellenebilir
    • moduleResolution: classic desteklenmiyor; bundler veya nodenext öneriliyor
    • esModuleInterop ve allowSyntheticDefaultImports, false olarak ayarlanamaz
    • alwaysStrict, true kabul edilir ve false olarak ayarlanamaz
    • namespace bildirimlerinde module anahtar sözcüğü kullanılamaz
    • import’larda asserts anahtar sözcüğü kullanılamaz; ECMAScript import attribute söz dizimi değişikliğine uygun olarak with kullanılmalıdır
    • skipDefaultLibCheck altında /// <reference no-default-lib /> yönergesi artık dikkate alınmaz
    • Geçerli dizinde tsconfig.json varsa komut satırı build’inde dosya yolu verilemez; açıkça --ignoreConfig gerekir

Şablon literal tipleri ve JavaScript desteği değişiklikleri

  • TypeScript 7.0, şablon literal tipi çıkarımında Unicode code point’leri daha doğal biçimde işler
type HeadTail<S> = S extends `${infer Head}${infer Tail}` ? [Head, Tail] : never;

type Result = HeadTail<"😀abc">;
// 7.0: ["😀", "abc"]
// 이전: ["\ud83d", "\ude00abc"]
  • Önceden JavaScript’in UTF-16 indexing davranışı izlenerek "😀", surrogate pair’in iki parçasına ayrılıyordu
  • Yeni davranış, for...of veya [...str] gibi "😀" karakterini tek birim olarak ele alma sezgisiyle uyumludur
  • UTF-16 code unit’lerini bilinçli olarak modelleyen tip düzeyi string işlemleri için breaking change olabilir
  • JavaScript desteği, TypeScript dosyalarının analiz yöntemiyle daha tutarlı olacak şekilde yeniden düzenlendi
    • Tip konumunda değerler kullanılamaz; typeof someValue kullanılmalıdır
    • @enum artık özel olarak ele alınmaz
    • Tek başına ? tip olarak kullanılamaz; any kullanılmalıdır
    • @class, fonksiyonları constructor yapmaz; class bildirimi kullanılmalıdır
    • Postfix ! desteklenmez
    • Tip adları @typedef etiketi içinde tanımlanmalıdır
    • Closure tarzı fonksiyon söz dizimi artık desteklenmez; TypeScript kısaltma söz dizimi kullanılmalıdır
  • this aliasing ve fonksiyon prototypeunun tamamen yeniden atanması gibi bazı JavaScript kalıpları da artık özel olarak ele alınmaz
  • TypeScript 6.0 ile 7.0 arasındaki farklar CHANGES.md dosyasında daha ayrıntılı olarak derleniyor

Düzenleyici özellikleri ve sınırlamalar

  • TypeScript 7.0’a, beta sürümünden sonra eksik kalan çeşitli düzenleyici özellikleri eklendi
  • Otomatik import, genişletilebilir hover, inlay hint, code lens, go-to-source-definition, JSX linked editing, tag completion gibi özellikleri içeriyor
  • TypeScript 7.0 beta’da eksik olan semantic highlighting, “sort imports”, “remove unused imports” gibi özellikler de eklendi
  • Dil sunucusu kalitesi için test ve tanılama altyapısı yeniden oluşturuldu; GitHub’daki başlıca TypeScript ve JavaScript kod tabanları üzerinde fuzz testleri çalıştırılabiliyor

Yerleşik dil iş akışlarının mevcut kısıtları

  • Vue, MDX, Astro, Svelte gibi araçları kullanan iş akışlarının henüz TypeScript 7’den yararlanamama olasılığı yüksek
  • Angular template’leri gibi özel template tür denetimleri de TypeScript 7’yi kullanamayabilir
  • Bunun başlıca nedeni, TypeScript 7’nin henüz kararlı bir programlama API’si sunmaması
  • Volar gibi TypeScript’i kendi derleyicisine ve dil servisine gömen araçlar şu anda TypeScript 6.0’a bağımlı kalmak zorunda
  • TypeScript ekibi bunu belirli bir döneme özgü bir kısıt olarak görüyor ve ilgili proje bakımcılarıyla birlikte çalışarak TypeScript 7 desteğini sağlamayı planlıyor
  • O zamana kadar, language server plugin gerektirmeyen senaryolarda TypeScript 7 kullanılması öneriliyor
  • Angular projeleri, CLI’da proje genelindeki hataları hızlıca tespit etmek için TypeScript 7’nin tsc aracını kullanıp, düzenleyici desteği için TypeScript 6.0’ı birlikte kullanabilir
  • Vue, MDX, Astro, Svelte gibi araçların bir süre daha TypeScript 6.0’ı kullanmaya devam etmesi gerekiyor
  • VS Code’da “Disable TypeScript 7 Language Server” komutuyla TypeScript 6.0’a geri dönülebilir

Gelecek planları

  • TypeScript 7.0 sürümü, TypeScript projesinin bir yılı aşkın süredir odaklandığı yerel port için önemli bir kilometre taşı
  • 7.0’dan sonra yeni özellik çalışmaları, kullanılabilirlik iyileştirmeleri, ek performans geliştirmeleri ve ekosistem için yeni API uygulamalarına geri dönülmesi planlanıyor
  • TypeScript 7.0 öncesine benzer şekilde 3-4 ayda bir yeni özellik sürümleri çıkarılması bekleniyor
  • TypeScript 7.1’de topluluğun geçişine yardımcı olmak için farkların kapatılması ve yeni API’lerin sunulması planlanıyor

İlgili okumalar

2 yorum

 
GN⁺ 2 시간 전
Hacker News görüşleri

  • Kendi testlerine göre TypeScript 7 için hız artışı rakamları şöyle

    Codebase TypeScript 6 TypeScript 7 Speedup
    vscode 125.7s 10.6s 11.9x
    sentry 139.8s 15.7s 8.9x
    bluesky 24.3s 2.8s 8.7x
    playwright 12.8s 1.47s 8.7x
    tldraw 11.2s 1.46s 7.7x

    Sorumlu bir şekilde geçiş yaparken bu kadar sonuç alan ekip gerçekten etkileyici. Bun keşke biraz bakıp ders alsa. Merak ettiğim şey, tsdown ya da esbuild gibi TypeScript codebase'ini derlemesi gereken alt araçları nasıl etkileyeceği ve TS 7 ile mevcut tsdown'ın birlikte kullanılıp kullanılamayacağı

    • esbuild TypeScript'e hiç bağımlı olmadığı için sorun yok. tsdown ise --isolatedDeclarations kullanıp kullanmadığına bağlı; kullanmıyorsa blogdaki yönlendirmeye göre TypeScript 6'yı yan yana kurmak yeterli
    • Bun'un geçişinin sorumsuzca olduğunu mu düşünüyorsun, merak ettim

  • Eskiden tiplerin harcanan emeğe değmediği tartışılan zamanlar da vardı. TypeScript'in iyi olmasının en büyük nedeni, her şeyden önce tipleri yaygınlaştırmış olması

    • Tiplerden nefret eden birini pek hatırlamıyorum. Birçok insanın sevmediği şey statik tipleme, daha doğrusu statik ve açık tiplemeydi
      Örneğin Python'un tipleri olmadığı için kullanılamaz olduğuna benzer sözleri birçok kez duydum; bu doğru değil. Python güçlü tipli bir dil ve aynı zamanda sadece dinamik tipli bir dil.
      Gerçekten tipi olmayan ya da genelde “stringly typed” denen diller de var. Çocukken kurcaladığım AREXX'te sayı gibi görünse bile tüm değerler string'di; sed gibi Unix CLI araçlarının çoğu da böyle görülebilir. Ama tiplerle ilgili tartışmaların çoğu Python gibi dinamik tipli diller etrafındaydı; zayıf tipli ya da tipsiz dillerin büyük projeler için iyi olduğunu söyleyen pek kimse görmedim. Aksine Python'u yanlış biçimde “tipi yok” diye adlandırıp büyük projelerde kullanılamayacağını söyleyenleri çok duydum; gerçekten Python ile büyük ölçekli projeler geliştiren biri olarak bu kafa karıştırıcıydı
    • Eski tip sistemleri zaten pek iyi değildi. Sum types gibi “OR” tiplerini ifade etmek için sınıf hiyerarşileri dayatılması acı verici. TypeScript, Rust, Swift, Kotlin gibi sum type'lara sahip modern diller çok daha rahat
    • Kişisel olarak, neredeyse birebir “JavaScript'te tipleme hatası yaşadığımı hiç görmedim” diyen kişilerle üç kez konuşmuşluğum var. Bunlardan ikisi çalışmalarına saygı duyduğum kişilerdi; nasıl böyle bir pozisyona sahip olabildiklerini anlamak zordu
    • Cebirsel veri tipleri ve pattern matching'in oyunu değiştirdiğini düşünüyorum. Haskell kadar aşırıya kaçmadan da tipler bir anda çok daha kullanışlı hale geldi
      Eskiden tiplere maruz kalma çoğunlukla C++/Java üzerinden oluyordu; özellikle C++ ise aşırı karmaşık bir dil nasıl yapılır dışında pek bir şeyin iyi örneği sayılamaz. Tiplerin iyi uygulanmış halini bir kez görünce ikna etmek çok daha kolay
    • Şimdi sadece DependentTypeScript'i bekliyorum

  • Burada gerçekten etkileyici olan şey, insanlığın bildiği en gelişmiş tip sistemi için iki ayrı codebase'i aynı anda sürdüren harika ekip. Rust yeniden yazımını da bekliyorum

    • Rust ile yeniden yazmanın anlamlı olup olmayacağından emin değilim. Go ile kod yazmak hızlı ve koda bakarak TypeScript'i 1:1 yeniden uygulamak kolay
      Rust geliştirme süresi çok daha uzun olacaktır. Rust Go'dan %20 hızlı olabilir, ama TypeScript'ten Go'ya geçişle elde edilen iyileşme zaten yeterince büyük. vscode'da Go ile 11 kat yerine Rust ile 14 kat görülebilir belki, ama Go tek başına bile büyük fark yaratmak için yeterli
    • En karmaşık denebilir belki ama “en gelişmiş” tip sistemi mi, emin değilim. Bu unvan için tek bir doğru cevap yoktur muhtemelen; ancak proof assistant dillerinden biri daha makul aday gibi geliyor
      TypeScript'in tip sistemini küçümsemek istemiyorum; gerçekten çok ilginç bir çalışma
    • Hugo'yu ve birçok önemli Go projesini yapan Steve Francia'nın ajan çağında Go hakkında yazdığı bir yazı var: https://spf13.com/p/go-the-agentic-language/
    • “İnsanlığın bildiği en gelişmiş tip sistemi” tam olarak ne demek, merak ediyorum
    • Rust vb. de ciddi şekilde değerlendirildikten sonra Go'nun seçildiğini biliyorum. Nedenlerinin hepsini hatırlamıyorum ama orijinal blog yazısında ayrıntılı anlatılmıştı

  • Birkaç yıl TypeScript kullandıktan sonra Python'da tip açıklamalarını elle eklemek ve abc gibi temel dil özelliklerini içe almak gerçekten zahmetli gelmeye başladı

  • İlginç, ama artık Node TypeScript tip açıklamalarını native olarak kaldırdığı için TSC'yi neredeyse hiç çalıştırmıyorum. Ancak büyük bir geriye dönük uyumsuz değişiklik yaptığımda ve güncelleyemediğim kısımları derleyicinin statik çıktısıyla görmem gerektiğinde çalıştırıyorum
    Tarayıcıya gidecek frontend kodu için de Node'un tip kaldırmasına dayanıyorum

    • Doğru, ama öte yandan editör bütün gün TypeScript dil sunucusunu çalıştırıyor. Muhtemelen CI da öyle; yapay zeka ajanı da az önce yaptığı işten emin olmadan önce bunu yapacaktır

  • JSDoc tip sözdiziminin ilgi görmeye devam etmesine seviniyorum. Kişisel projelerde TypeScript kullanmanın en sevdiğim yolu bu. Bazı sözdizimi değişikliklerini güncellemek zahmetli olacak, ama çoğu daha iyiye gidiyor gibi görünüyor

  • TypeScript’in büyük sancılarından biri, projenin bazı bölümleri için lib ve types gibi tsconfig ayarlarının kapsamını ayarlamanın zor olması.
    Proje bir web uygulaması, ama vite.config.ts, Playwright ve birim testleri nedeniyle IDE araçları tarafına Node tipleri giriyor. Bir React bileşenine Node API’si ekleseniz bile tsc şikâyet etmiyor.
    Şu anda DOM kütüphaneleriyle Node kütüphanelerini yalıtmak için proje referansı spagettisi, çok sayıda tsconfig.json ve tsbuildinfo çıktı dosyası gerekiyor; proje referansları kullanırken tip çıktısından kaçınmak da zahmetli.

    • Gerçekten acı veren kısma katılıyorum. nx kullanıyorum ve bunları benim yerime hallediyor. Playwright, kendi tsconfig’ine sahip ayrı bir proje ve hepsi kök tsconfig’ten miras alıyor.
      Tek bir uygulamada bile nx’i tercih ediyorum; paylaşılan kodu da “kütüphane”ye taşıyorum. Build edilmeyen kütüphaneler kullanıyorum; büyük projelerde oldukça iyi oluyor.

  • Henüz TypeScript compiler API yok, ama üzerinde çalışıldığını söyledikleri için umut verici.

    • 7.1’e girmesi planlanıyor.

  • Bellek kullanımı azalırken performansın ciddi arttığını gösteren grafikleri görünce, sunucu tarafında TypeScript değil Go kullanmak gerekmez mi diye düşündürüyor.

    • Öncelikle sunucu tarafında TypeScript çalıştırmıyorsunuz. Hangi yürütme motorunu kullanırsanız kullanın, dönüştürülmüş kodu ya da JavaScript’i çalıştırıyorsunuz.
      Ayrıca bu kadar seçenek varken neden hâlâ TS/JS/Python ile yeni proje başlatanlar var, pek anlayamıyorum.
    • Frontend projesiyle tipleri veya modülleri paylaşabilmek için olabilir. CPU yoğun olmayan uygulamalarda neredeyse fark olmaması da bir neden olabilir; alışık olup sevdikleri için de olabilir. Kütüphane ekosisteminin inanılmaz büyük olması da var.
    • Bu build zamanı performansı, çalışma zamanı performansı değil.
    • Go ile JS’in (Node vb.) performans farkının önemli olup olmadığı kullanım durumuna bağlı. TypeScript derleyicisi için kesinlikle önemli, ama bir CRUD uygulaması için hiç önemli olmayabilir.
    • Mümkünse tek bir ana dille çalışmak daha kolay olduğu için.

  • TypeScript ekibini tebrik ederim. Uzun uzun yazı ya da ses kaydı olarak paylaşabileceğim şeyler var ama kısaca söylersem JavaScript/TypeScript ekosistemi ahşapla çalışmaya benziyor.
    Ucuz lamine sunta malzeme, Ikea tarzı şeyler de yapabilirsiniz. Kod tarafında bu, özgünlüğü olmayan vibe coding uygulamaları olurdu.
    Öte yandan üst düzey el yapımı mobilyalar ya da ahşap yüksek binalar da mümkün. Genç keresteyi kullanıp özel geçmeler ve laminasyon teknikleriyle yangına dayanıklı kirişler yapmak gibi. JavaScript/TypeScript ekosisteminde de yapay zekayı güçlü bir takım tezgâhı gibi kullanıp zanaatkârlıkla yüksek kaliteli sonuçlar üretmek mümkün. Bir şeyler yapıp çalıştırma cesaretiniz varsa TypeScript/JavaScript ekosistemini benimsemeniz yeterli.
 
GN⁺ 2 시간 전
Lobste.rs yorumları

  • Gerekçeyi anlıyorum ama kendi kendini barındıran derleyiciden kendi kendini barındırmayan bir derleyiciye geçmeleri ilginç
    Genelde neredeyse her zaman ters yönde gidildiği için nadir görülen bir akış

    • Bu yönü daha sık görmemiz gerektiğini düşünüyorum. Her dil derleyici yazımı için uygun değildir
      Kendi kendini barındırma, dilin derleyici yazmaya daha uygun bir dile evrilmesi için güçlü bir baskı oluşturur; bu da her zaman doğru yön olmayabilir
    • Dil tasarımcıları ve uygulayıcılarının kendi dillerinin her kullanım için mükemmel olmadığını anlaması şaşırtıcı

  • TypeScript ile kod yazmasam bile VSCode’un kendisi TypeScript ile yazıldığı için, bu iyileştirmenin VSCode hızı üzerinde de etkisi olup olmadığını merak ediyorum
    Yoksa yalnızca TypeScript dil eklentisini mi etkiliyor, onu merak ediyorum

    • Hızlanan şey derleyici; sihirli biçimde daha hızlı kod üretmiyor
    • Yalnızca TypeScript dil eklentisi için geçerli
    • TypeScript, JavaScript’e derlenir. VSCode çalışırken node.js ve Chromium JavaScript kodunu çalıştırır
      Burada hızlanan tek şey TypeScript kodunu alıp JavaScript’e dönüştüren derleyici; bu süreç Microsoft’un VSCode çalıştırılabilir dosyasını dağıtmadan önceki build pipeline’ında gerçekleşir
      Olası bir istisna, TypeScript LSP sunucusunun da hızlanabilmesi olabilir; çünkü bu sunucu çalışma sırasında gerçekten TypeScript kodunu parse eder. Ancak bu, VSCode’un TypeScript ile yazılmış olmasından bağımsızdır
    • TypeScript derleyicisi aslında çok fazla iş yapmaz. tsc, tipleri kaldırma gibi asgari işlemler dışında işlediği koda dokunmaması gerektiği ilkesi nedeniyle WONTFIX olarak işaretlenen epey şey barındırır
      Bu yüzden TypeScript ile yapılmış araçların performans özelliklerinin neredeyse değişmeyeceğini bekliyorum

  • Kişisel olarak edindiğim küçük bir ipucu. Şu an üzerinde çalıştığım proje TS 5 kullanıyor ama tahmin edileceği gibi nvim’de onu kullanmak istemedim
    Bu yüzden önce mise ile TS 7’yi kurdum ve node_modules/.bin içine mise ile kurduğum TS’yi gösteren bir tsgo sembolik bağlantısı oluşturdum
    nvim-lspconfig hâlâ teknik önizleme dönemindeki eski tsgo dosya adını kullandığı için nvim, yerel TS yerine kurduğum TS 7’yi çalıştırıyor