Node.js, ek yapılandırma olmadan TypeScript dosyalarını çalıştırmayı destekliyor

• Node.js, TypeScript dosyalarını doğrudan çalıştırabilecek şekilde geliştirildi
• Artık ek yapılandırma ya da transpile işlemi olmadan .ts dosyaları doğrudan çalıştırılabiliyor
• Geliştiriciler, tsconfig.json veya ayrı bir bundler kurmadan çalışma verimliliğini artırabiliyor
• Bu özellik, Node.js v22.18.0 (LTS) sürümünden itibaren resmen eklendi
• JavaScript ve TypeScript geliştirme arasındaki sınırların yumuşaması bekleniyor

---

Node.js'te TypeScript'i doğrudan çalıştırma desteği

• Node.js, yakın zamanda yayımlanan v22.18.0 (LTS) sürümünde, TypeScript dosyalarını (.ts) ayrı bir yapılandırma veya araç olmadan doğrudan çalıştırabilen bir özellik sundu
• Daha önce TypeScript kodunu çalıştırmak için ts-node, esbuild, Babel gibi harici transpiler'lar veya bundler'lar gerekiyordu; artık bu araçlar olmadan da Node.js kendi içinde TypeScript kodunu tanıyıp çalıştırabiliyor
• Bu özellikle birlikte geliştiriciler, tsconfig.json yapılandırma dosyası veya ek kütüphaneler olmadan .ts dosyalarını doğrudan Node.js üzerinde çalıştırabiliyor
• Prototipleme, deneysel geliştirme ve script çalıştırma gibi alanlarda üretkenlik ve geliştirme kolaylığı önemli ölçüde artıyor
• JavaScript ve TypeScript projeleri arasındaki birlikte çalışabilirliğin güçlenmesi ve yeni geliştiriciler için giriş engelinin azalması bekleniyor

Diğer dikkat çekici değişiklikler

• esm: import.meta.main uygulandı
• fs: AsyncIterator tabanlı fs olay işleme geliştirildi
• permission: Alt süreç çalıştırılırken izin modeli bayrağının aktarımı destekleniyor
• sqlite: readBigInts seçeneği eklendi
• src/permission: permission.has(addon) desteği eklendi
• url: fileURLToPathBuffer API'si eklendi
• watch: --watch-kill-signal bayrağı eklendi
• worker: Worker nesnesi async disposable olacak şekilde geliştirildi

Commit ve dokümantasyonla ilgili güncellemeler

• Gereksiz kodların kaldırılması, build ortamı ve araç zincirinin düzenlenmesi, ayrıca npm 10.9.3 yükseltmesi dahil
• globals.md, child_process.md, http2 gibi dokümanlarda ayrıntılı kararlılık göstergeleri ve RFC numaraları düzeltildi
• Çok sayıda test eklendi ve hata düzeltmeleri yansıtıldı

Dağıtım dosyaları

• Windows, macOS (Intel/Apple Silicon) ve Linux (x64, ARM, PPC, s390x, AIX) için kurulum dosyaları ve ikili dosyalar sağlanıyor
• Kaynak kodu ve tüm sürüm dosyaları Node.js'in resmi dağıtım sayfasından indirilebiliyor
• API dokümantasyonu v22.18.0 temel alınarak güncellendi

[aliveornot]

İçim gerçekten ferahladı... umarım kısa sürede yaygınlaşır

[tested]

Basit script’leri çalıştırmak için fena değil gibi görünüyor ama canlı projelerde kısıtları çok olduğu için pek kullanılacakmış gibi görünmüyor.

ERR_MODULE_NOT_FOUND/ERR_UNSUPPORTED_DIR_IMPORT hataları yüzünden uzantıları ve yolları da doğru ayarlamak gerekiyor
NestJS gibi emitDecoratorMetadata ayarıyla TypeScript build desteği gereken özellikler de kullanılamıyor, o yüzden...

[kimjeongwonn]

--experimental-strip-types varsayılan olarak mı etkinleşiyor?

[click]

Zaten enum kullanmadığım için, benim ölçütlerime göre yalnızca tip kaldırma davranışıyla bile gayet iyi çalışıyordu.

[crawler]

Çok daha kullanışlı olacak gibi görünüyor!

[honglu]

Beğenimi tutamıyorum.

--no-experimental-strip-types bayrağının bile fazlasıyla iyi olduğunu düşünmüştüm.

Üstelik bu daha da iyi görünüyor.

[GN⁺]

Hacker News görüşleri

• Node.js'te node:test ile birlikte artık çoğu durumda Node.js'in ikna edici varsayılan seçenek olduğunu düşünüyorum. tsx kullanarak çalıştırmak yaşam kalitesini ciddi biçimde artırmıştı, ama yine de tam değildi. zod, ts-rest ve trpc gibi araçlarla edge tarafındaki çalışma zamanı tip doğrulaması büyük ölçüde çözülüyor ve bugünlerde full-stack TypeScript geliştirmek gerçekten çok kolaylaştı
  • Kesinlikle. 2025'e geldik ve sonunda Node ekosistemi varsayılan ayarlarla kullanılabilir hale geldi. ESM modülleri hem Node hem de TypeScript tarafında artık sorunsuz çalışıyor, Node .ts dosyalarını doğrudan çalıştırabiliyor ve iyi seviyede yerleşik bir test runner sunuyor (--watch destekli). Yerleşik paketler de daha iyi hale geliyor. node:fs/promises gibi şeyler ve top-level await sayesinde asenkron döngü işleri çok daha kolaylaştı. Herkesi buna gerçekçi bir seçenek olduğuna ikna etmek uzun sürdü ama artık gerçekten keyifli bir noktadayız
  • Node'da TypeScript'in doğrudan desteklenmesini güçlü biçimde destekliyorum. vitest bugünlerde pek çok şeyi rahatlatıyor ama .ts dosyaları için test ortamı yapılandırmaya gerçekten çok zaman harcamıştım. trpc ve ts-rest'in ise tamamen farklı bir sorun olduğunu düşünüyorum. İkisi de kullanılabilir ama production'da trpc'den kaçınıyorum; çünkü API URL'lerini doğrudan sahiplenemiyorum, eski URL'leri doğal biçimde yönetip aşamalı olarak kaldıramıyorum. ts-rest için de genelde zod ve tipleri doğrudan paylaşıp API istek/yanıt çiftlerini kendim yönetmeyi tercih ediyorum. Bir de trpc bariz şekilde bir RPC aracı iken adında -rest geçmesi her seferinde rahatsız ediyor
  • Bundan sonra Sveltr'ın kod tabanını yeniden TypeScript'e taşıyıp taşımayacağını izleyeceğim
  • Bunun tsx çalıştırmak anlamına gelip gelmediğini merak ediyorum. Tipleri çıkarsanız bile JSX'i JavaScript'e dönüştürmeniz gerekiyor; benim merak ettiğim kısım da bu
  • Ben kısa süre önce Python'a geçtim. Her şey yerleşik geliyor; bu yüzden tamamlanmamış bir sistemin çeşitli tuhaf sorunlarını debug etmek zorunda kalmamak beni çok daha memnun ediyor
• Node'un son birkaç yıldaki ilerleyişinden gerçekten etkilendim. deno ve bun'ın Node'u dürtüp odaklı ve anlamlı iyileştirmeler yapmaya zorlaması güzel oldu. Bir süre duraklamıştı
  • Node'da yakın zamanda ne gibi iyileştirmeler olduğunu merak ediyorum. Bana son anlamlı gelen iyileştirme import/export desteğinin resmileşmesiydi (.mjs hilesine hâlâ ihtiyaç var mı bilmiyorum). Bir süredir ekosistemden uzaktım; o zamandan beri nelerin değiştiğini öğrenmek isterim
  • Gerçekten öyle miydi emin değilim. İçinde bulunduğum projelere bakınca deno ya da bun olmasa da gayet olurdu. Fiilen anlamlı olan şey node LTS sürümleri ve yeni projeler bile hâlâ node 20 kullanıyor
• TypeScript'in node_modules içinde kabul edilmemesi üzücü (ilgili: node.js resmi belgeleri). Peki o zaman proje bağımlılıkları nasıl olacak merak ediyorum. Veri modeli için bir kütüphaneyi TypeScript ile yazdım ve bunu uygulamama TypeScript haliyle import etmek istiyorum. Bu kuralın yalnızca npm paketleri için mi, yoksa tüm bağımlılıklar için mi geçerli olduğunu merak ediyorum. Burada bir fırsat var. Ben JavaScript/TypeScript (daha doğrusu genel olarak JS) çalıştırmak için Go tabanlı bir runtime yaptım ve Grafana ekibinin kullandığı sobek de yalnızca tip soyma özelliği eklenirse yeterli gibi görünüyor. TypeScript'i varsayılan olarak tamamen benimseyen tek bir runtime ortaya çıksa Node.js'in gerçekten devrim niteliğinde olacağını düşünüyorum. Ne transpiler'a, ne typescript-go'ya, ne de Rust'a ihtiyaç var (gerçi Rust biraz olur😉); debug modunda source map ve tipleri izleyen iyi bir parser'a sahip bir sistem yeterli olur. Her hâlükârda Node ekibine ve tüm katkıda bulunanlara takdir ve teşekkürler. Standart olanın Node olması nedeniyle hepimiz onun ardından gidiyormuşuz gibi geliyor. Embedding API'si de basit ve kullanımı temiz; standalone üretirken de kullanışlı
  • Aynı yorumu daha önce de bırakmıştım (referans). Orada “TypeScript ile yazılmış paketlerin npm'e yayımlanmasının teşvik edilmemesi için” deniyor; ben de private paketle denedim ama çalışmadı ve Node private alanını hiç umursamıyor
  • Paketlerin npm'e yayımlanmadan önce mutlaka JavaScript'e derlenip öyle dağıtılması gerektiğini düşünüyorum. TypeScript'i olduğu gibi npm'e koymak için bir neden görmüyorum
• İlgili issue node_modules içinde tip soyma desteği olmaması bence üzücü
  • Bu özelliği istememin yarısı tam da buydu. Kütüphaneleri TypeScript ile yazıp tip denetimini yalnızca CI/CD'de yapmayı, ardından doğrudan Node.js'te import edebilmeyi umuyordum
  • Bunun doğru karar olduğunu düşünüyorum. TypeScript'te breaking change'ler epey sık yaşanıyor. Standartlaşmadığı sürece mevcut yaklaşımın daha iyi olduğunu düşünüyorum
• JS/TS tarafını yoğun kullanan biri değilim ama doğrudan Bun kullanmak daha iyi değil mi diye merak ediyorum. Elbette her proje sıfırdan başlamıyor ama genel olarak Bun'ın daha iyi bir runtime olduğunu hissettim. TS çalıştırma en baştan var, bağımlılık çözümleme çok daha hızlı ve kullanılabilirliği de çok iyi. Ben şahsen birçok eski Node projesini Bun'a taşıdım ve Bun çıktıktan sonra neredeyse hiç Node kullanmadım. Yanlış düşündüğüm bir nokta varsa lütfen söyleyin
  • Yaklaşık 8 yıl sadece Node kullandıktan sonra yakın zamanda Deno'ya geçtim. Bu geçiş de kolay olmadı; asıl korku bir şeyin şu an çalışmaması değil, ne zaman çalışmaz hale geleceğini bilememekti. Node'un kesinlikle eksikleri var ama sektörün fiili standardı hâlâ o. JS ekosistemi zaten yeterince kaotik; birçok geliştirici yeni build tool, bundler ve runtime'lardan yorulmuş durumda. Bun'ın gerçekten ikna edici olacak kadar yeterli istikrarı ve desteği henüz oluşmamış gibi geliyor. Daha önce TS'nin küçük bir güncellemesi yüzünden günlerce sorun çözdüğüm oldu
  • En yeni akımları kovalamaktan pek hoşlanmıyorum. NodeJS, JS ekosisteminde en iyi desteklenen runtime. Varsayılan seçim olan şeyi takip etmenin çok daha iyi olduğunu düşünüyorum. Sözde “sıkıcı” teknolojileri seçiyorum
  • Bun çıktıktan sonra tamamen geçmeyi defalarca denedim ama her seferinde yaklaşık %90 noktasında kaçınılmaz bir soruna çarptım. Son denememde bazı kütüphanelerde napi fonksiyonları implemente edilmediği için çalışmıyordu; opendir seçeneklerinde recursive'in yok sayılması gibi aklımda kalan sorunlar da vardı. Bun'ın yetişmesini bekliyorum ama henüz büyük projelerde profesyonel kullanım için hazır görünmüyor. Bun'a özel özellikler de ilk bakışta hoş dursa da pratikte yetersiz geliyor. Belgeleri de Node.js kadar kaliteli değil
  • Node'u Bun ile değiştirmeye çalışırken yaşadığım uyumluluk sorunları şunlardı.
• TCP bağlantılarında localAddress yok sayılıyor
• Node modül API'siyle uyumsuzluklar (örnek: spamscanner projesi çalışmıyor)
• EventEmitter ile ilgili race sorunları (kısmi çözüm: eventemitter2)
• Svelte vites dev sunucusu bazen takılıyor ve node_modules silinip yeniden kurulmak zorunda kalıyordu

  • Node'un kendi TS ve test runner özelliklerini denedim ama hâlâ Bun kadar iyi değiller. Şimdilik bu tür işler için Bun kullanıyorum. Node ekosisteminde tek bir şeye tamamen yüklenmektense, farklı araçları uzman oldukları alanlarda birlikte kullanmanın daha iyi olduğunu öğrendim.

    • Bun.js: Node runtime'ı için, TS çalıştırma ve testlerde kullanıyorum. TSX, TS-Node, Node'un kendisi gibi farklı seçenekleri de denedim

    • NPM: tooling script'lerini çalıştırmak için kullanıyorum

    • PNPM: bağımlılık kurmak için kullanıyorum. (npm, yarn, bun ile karşılaştırınca en iyisi olduğunu düşünüyorum)

    • Biome.js: linting için. Şimdiye kadar kullandığım tüm lint araçlarından daha iyi

• Bu iyileştirmenin yalnızca “type stripping” ile yapılmış olması gerçekten harika; source map gerektirmediği için production'da tam anlamıyla sıfır maliyetli oluyor. Node ekibi gerçekten iyi iş çıkarmış
• Tip soyma işlevi de (import { stripTypeScriptTypes } from 'node:module') dışa açılmış durumda. Frontend bağımlılığı olmayan basit bir web uygulaması geliştirirken her şeyi TypeScript ile yazıp frontend script'lerini sunarken yalnızca tipleri çıkarmak mümkün (örnek proje)
• Bu değişim sayesinde şirketimiz de sonunda TypeScript'e geçebildi. Birden çok servisi aynı anda TS'ye taşıdık; bazılarında geçiş hâlâ sürüyor. Büyük kazanım oldu
• Görünüşe göre çalışma biçimi tip bilgisini çıkarmak. Yani bir transpile adımını azaltıyor; güvenlik açısından ise bir iyileştirme getirmiyor
  • TypeScript'in temel tasarım hedefi, tiplerle ilgili sözdizimi çıkarıldığında ortaya geçerli bir JavaScript dosyası çıkmasıdır. TS derleyicisi kod üretmez (örneğin PureScript gibi değildir). tsc gibi tip denetleyicilerle statik kontrol yapılır ve tip bilgisi çıkarılır. Python da çalışma zamanında tip anotasyonlarını yok sayar; Java da bytecode'da bazı tip bilgilerini, örneğin generic'leri, siler
  • “En fazla transpile adımını azaltır, güvenliği artırmaz” demek biraz yanıltıcı olabilir. Node'un TS'yi doğrudan çalıştırabilmesi tip denetimi güvenliğini doğrudan artırmaz ama tip denetimi editörde ya da başka araçlarla ayrıca yapılabilir. Node'un TS'yi doğrudan çalıştırmayı desteklemesi, TS kullanımına giriş engelini ciddi biçimde düşürür ve dolaylı olarak tip güvenliğine yardımcı olur
  • TypeScript hiçbir zaman güvenliği artırmayı garanti ettiğini söylemedi. Bu yaygın bir yanlış anlama. TS'nin bir runtime modu ya da runtime bilgisi yoktu; tip denetleyiciyi çalıştırmazsanız ciddi tip hataları olsa bile kod yine çalışabiliyordu. Teknik olarak bakarsanız TypeScript bir bakıma linter'a daha yakındır
  • Build/transpile olmadan script'leri doğrudan çalıştırabilmek bence inanılmaz kullanışlı. Tip denetimi gerekirse tsc ile çalıştırma modeli bana çok uyuyor
  • Projelerimde tsx kullanarak aynı şekilde build/transpile gerektirmeden çalışan bir kurulum kullanıyorum. Geliştirme sırasında çok faydalı oluyor. tsx'in --watch özelliği sayesinde TS kaynaklarından doğrudan sunucu çalıştırıyor ve değişiklikte otomatik yeniden başlatıyor. Yakında nodemon ve Node'un yerleşik özellikleriyle benzer bir ortam kurulabilir gibi görünüyor. Runtime'da tip denetimi yapmak için bunun V8 seviyesinde desteklenmesi gerekir; bu da neredeyse baştan yazım ölçeğinde bir iş olurdu
• Gerçekte tüm TypeScript'i değil, yalnızca belirli bir alt kümeyi çalıştırıyor. Başlıktaki ifade biraz abartılı gelebilir. Böyle bir değişimin TS'yi sadece linter gibi kullanmaya itmesinden ve yalnızca tip soyma ile uygulanamayan çeşitli güçlü TS özelliklerinin geri planda kalmasından endişe ediyorum
  • TS'de soyma işlemiyle desteklenemeyen hangi özellikler var gerçekten merak ediyorum. enum dışında pratikte kullanılan başka ne var diye soruyorum