Node.js'ye deneysel TypeScript desteği eklendi

Modül: --experimental-strip-types eklendi

• Node.js'te TypeScript dosyaları çalıştırılabiliyor

  • --experimental-strip-types bayrağı ayarlanırsa TypeScript dosyaları çalıştırılabiliyor
  • Node.js, TypeScript kaynak kodunu JavaScript kaynak koduna dönüştürüyor
  • Dönüştürme sırasında tip denetimi yapılmıyor ve tipler kaldırılıyor

• Motivasyon

  • TypeScript dosyalarını harici bağımlılıklar veya yükleyiciler olmadan çalıştırabilmek önemli
  • Kullanıcıların node foo.ts komutunu çalıştırabilmesi isteniyor

• Tip sıyırmanın anlamı

  • Tip sıyırma, tüm tiplerin kaldırılıp girdinin bir JavaScript modülüne dönüştürülmesi anlamına geliyor
  • Örnek: const foo: string = "foo"; ifadesi const foo = "foo"; haline dönüştürülüyor

• Neden @swc/wasm-typescript seçildi

  • Basit olduğu için
  • Diğer araçlar ek olarak Rust veya Go gerektirirken, @swc/wasm-typescript küçük bir paket olarak yalnızca wasm ve js dosyalarına ihtiyaç duyuyor
  • Deno'da da kullanıldığı için güven veriyor

• Kısıtlamalar

  • Enum, namespace gibi TypeScript'e özgü özellikler dönüştürülmüyor
  • Uzantısız import desteklenmiyor

• GN⁺ özeti

• Node.js'te TypeScript dosyalarını çalıştırmayı mümkün kılan yeni bir özellik açıklanıyor

• TypeScript dosyaları JavaScript'e dönüştürülerek çalıştırılabiliyor, ancak tip denetimi yapılmıyor

• Bu sayede kullanıcılar TypeScript dosyalarını harici bağımlılıklar olmadan çalıştırabiliyor ve geliştirme ortamı sadeleşiyor

• Bu özellik @swc/wasm-typescript kullanılarak hayata geçirildi; ileride native katmanda uygulanması da değerlendiriliyor

• TypeScript ve JavaScript'i birlikte kullanan projeler için faydalı olabilir

[GN⁺]

Hacker News yorumları

• TypeScript'teki tipleri kaldırmak, TypeScript sözdizimi olmadan mümkün değil. Tip kaldırma işlemi token düzeyinde bir iş değil ve TypeScript sözdizimi de sürekli değişiyor

  • Örneğin, foo < bar & baz > ( x ) ifadesi TypeScript 1.5'te farklı yorumlanıyordu
  • Yeni TypeScript özelliklerini kullanmak için ya JS'ye derlemek ya da Node sürümünü güncel tutmak gerekir
  • Node LTS sürümlerini kullananlar için bu zor bir ödünleşim olabilir

• Eğer Node.js TypeScript dosyalarını doğrudan çalıştırabilirse, TypeScript derleyicisinin tipleri kaldırıp JavaScript'e dönüştürmesine gerek kalmaz

  • Bu, Python'daki duruma benziyor
  • Python'da birden fazla tip denetleyicisi var ve hepsi aynı type hint sözdizimini kullanırken farklı anlamlar uyguluyor
  • JavaScript tarafında ise TypeScript tek popüler tip denetleyicisi haline geldi
  • Python'da type hint'leri yorum gibi kullananlar da var
  • Node.js'te tipleri yok sayma desteği gelirse, bu JavaScript'te de mümkün olur

• Eğer bu özellik varsayılan hale gelirse NPM ekosisteminin nasıl tepki vereceğini merak ediyorum

  • NPM modülü yayımlarken CJS ve EJS sürümlerini oluşturmaya devam mı edilecek, yoksa package.json içine engine: nodejs >= 25 eklenip build adımı mı atlanacak, emin değilim
  • Kişisel olarak TS ile yazılmış NPM modüllerinin artık dist/.cjs sağlamamasını isterim
  • Build adımını atlamak, NPM katkıcıları için cazip olacaktır
  • Bu durum NPM ekosisteminde dalga etkisi yaratabilir
  • Node.js bu özelliği deneysel bayrak olmadan sunarsa, tüm tüketicilerin TS dosyalarını kabul edeceği varsayılacaktır
  • Bu da Firefox ve Safari'yi TS dosyalarını kabul etmeye zorlayabilir
  • Ben şahsen JS derleyicilerinin TS tip açıklamalarını atmasını memnuniyetle karşılarım
  • Node'un .ts dosyalarını kabul etmesi, transcompile adımını ortadan kaldırabilir

• Node'un JS içinde tipleri inceleyebilmesi büyük bir kazanım olur

  • Python'da pydantic gibi araçlar var; bunlar tipleri inceleyip doğrulamalar üretiyor
  • Bu sayede tek bir standart gösterimle tip denetimi, çalışma zamanı veri doğrulaması, API üretimi ve API dokümantasyonu mümkün oluyor
  • Şu anda JS tarafında bunun için zod gibi araçlara ihtiyaç var

• Bun'ın geliştirici deneyimi (DX) bu alanda eşi benzeri görülmemiş düzeyde ve kullanım senaryolarının çoğunu karşılıyor

  • Node'da import sırasında uzantı gerekmeyecek şekilde ayar yapılamıyor ve tsc'nin .js uzantılarını otomatik eklemesi de sağlanamıyor
  • Yerel TypeScript desteği bunu çözebilir, ama Bun'ın kullanıcı deneyimi veya performansını yakalaması zor olur

• TypeScript'i çok seviyorum ve uzun zamandır bir TypeScript runtime istiyordum

  • Java'dan ayrılma sebebim, daha fazla özelliğe sahip bir tip sistemi ve kademeli tipleme istememdi
  • npm ekosisteminin dezavantajlarına rağmen kütüphaneleri kullanmak daha az zahmetli ve daha eğlenceli
  • Rust başka bir dil spektrumunda olsa da benzer bir his veriyor
  • JIT yanlış bir terimdi; aslında JVM ile V8'in başlangıç süresi ve çalışma zamanı farklarından söz etmek istemiştim

• En sevdiğim deno özelliği doğrudan Node'a geliyor

  • esbuild kurmadan tipleri kaldırabilecek olmak beni çok heyecanlandırıyor
  • Son zamanlarda Python'ı tercih ediyordum ama tipler açısından TypeScript, Python'dan daha iyi
  • Büyük script'ler, tip olduğunda çok daha fazla fayda sağlıyor

• Node için çok önemli bir aydı

  • v22.5.0 ile node:sqlite eklendi, şimdi de TypeScript desteği geliyor
  • Node'un gittiği yönü beğeniyorum

• PR'nin yazarıyım, AMA

• Uzun zaman önce backend işleri için Node.js kullanmaya başladım ve PHP'ye göre çok daha fazla avantaj sağlıyordu

  • Node biraz zahmetliydi ve istenen dil haline getirmek için parçaları birleştirmek gerekiyordu
  • Golang kullanmaya başladım ve tip güvenliği sayesinde kod yazmak daha kolay hale geldi
  • TypeScript iyi bir seçenek ama yine de sadece ek bir katman
  • Node kullanmanın büyük avantajı prototip geliştirme hızı ve TypeScript kullanımı bu avantajı dengeleyebilir