Deno 2.4 sürümü yayımlandı

• deno bundle, esbuild tabanlı olarak yeniden sunuldu; böylece hem sunucu hem de tarayıcı için tek dosyalık bundle üretimi ile otomatik tree shaking ve optimizasyon mümkün hale geldi
• Metin/bayt importu desteği ve yerleşik OpenTelemetry’nin kararlı hale gelmesi ile gözlemlenebilirlik ve harici dosya kullanımı deneyimi güçlendirildi
• Yeni --preload bayrağı, bağımlılık kolaylıkları sağlayan deno update, script coverage ölçümü, izin yönetimi ve Node.js API uyumluluğu dahil olmak üzere geniş kapsamlı iyileştirmeler yapıldı
• LSP, Jupyter, bench/coverage, tsconfig desteği geliştirildi ve çeşitli kullanım kolaylığı iyileştirmeleri de sunuldu

---

Deno 2.4’teki başlıca değişiklikler ve yeni özelliklerin özeti

deno bundle geri döndü

• Deno 2.4 ile, tek dosyalık JavaScript bundle üretme özelliği sunan deno bundle alt komutu esbuild motoruyla birlikte yeniden eklendi
• Hem sunucuyu hem de tarayıcıyı destekliyor; npm, JSR bağımlılıkları da sorunsuz biçimde bundle içine alınabiliyor
• Otomatik tree shaking ve kod optimizasyonu (minify) desteği sayesinde yönetimi daha kolay bir ortam sağlıyor
• Gelecekte runtime API ve plugin desteğiyle bundle sürecinin programatik olarak genişletilmesi ve özelleştirilmesi planlanıyor

Metin ve bayt importu desteği

• JavaScript modül grafiğine metin, ikili veri, görsel gibi harici veri dosyalarını gömebilmek için --unstable-raw-imports bayrağı sunuluyor
• Daha önce harici dosyaları dosya G/Ç (I/O) ile okumak gerekirken, artık import sözdiziminde dosya tipini belirterek bayt/metin verisini doğrudan kullanmak mümkün
• Bu özellik bundle ve derleme sırasında da çalışıyor; böylece çıktıya asset embedding uygulamak kolaylaşıyor
• JSON, Wasm gibi mevcut import desteğiyle birlikte çeşitli dosya formatları spesifikasyona dost bir şekilde yönetilebiliyor
• Özellik için spesifikasyon tartışmaları hâlâ sürse de Deno, işlevsel ilerleme ile standart eğilimlerini dengeli biçimde yansıtıyor

Yerleşik OpenTelemetry kararlı hale geldi

• 2.2 sürümünde sunulan yerleşik OpenTelemetry desteği, 2.4 ile tamamen kararlı hale geldi
• Yalnızca OTEL_DENO=1 ortam değişkenini ayarlayarak ek bir bayrak olmadan log, metrik ve trace toplama otomatikleştirilebiliyor
• Node.js ile sıfır yapılandırmalı uyumluluk ve Deno Deploy dağıtım ortamı için toplu destek sunuluyor
• console.log kayıtları ile HTTP isteklerinin otomatik ilişkilendirilmesi/gözlemlenmesi de mümkün
• Kaynak kullanımı özellikleri nedeniyle ortam değişkeniyle kontrol gerekebiliyor

Çalıştırma öncesi ortam hazırlığı için --preload bayrağı

• Ana script çalışmadan önce global ortamı değiştirme, veri yükleme, bağımlı modülleri kaydetme gibi işlemler için kodu önceden çalıştırabilen --preload bayrağı eklendi
• Platform özelleştirme veya global nesneleri yeniden ayarlama gibi çeşitli platform kurulum senaryolarında faydalı
• deno run, deno test, deno bench gibi başlıca komutların tamamında kullanılabiliyor

Bağımlılık yönetimini sadeleştiren: deno update

• npm ve JSR bağımlılıklarını en son sürümlere otomatik güncellemek için deno update alt komutu eklendi
• Birden fazla bağımlılığı tek seferde güncelleme ve Semver uyumluluğuna dayalı hassas güncelleme desteği sunuyor
• Mevcut deno outdated --update için takma ad da sağlanarak kullanım kolaylığı artırıldı

Script coverage: deno run --coverage

• Yalnızca testler için değil, subprocess içeren tüm çalıştırma süreci için coverage toplanabiliyor
• DENO_COVERAGE_DIR ortam değişkeni gibi farklı yöntemlerle esnek veri yönetimi yapılabiliyor
• HTML coverage raporuna karanlık mod desteği eklendi

Deno uyumluluk ortam değişkeni DENO_COMPAT=1

• npm ekosistemi ve package.json tabanlı projelerde kullanım kolaylığı ve uyumluluğu artırmak için DENO_COMPAT=1 değişkeni sunuldu
• Birden fazla kararsız (Unstable) bayrağı otomatik uyguluyor; gelecekte npm prefix atlama gibi desteklerin daha da genişletilmesi planlanıyor

İzin yönetimi ve güvenlik iyileştirmeleri

• --allow-net bayrağında alt alan adı wildcard ve CIDR aralığı desteği eklendi
• Kodun import edebileceği host’ları sınırlayan --allow-import ve açıkça engelleyen --deny-import bayrakları eklendi
• Deno.permissions API’sinde "import" türü sorgusu resmî olarak destekleniyor
• Deno.execPath() kullanırken artık okuma izni gerekmiyor; çalıştırılabilir dosya yolundan yararlanmak kolaylaştı

Koşullu package.json exports

• npm paketlerinde koşullu exports desteği geldi; özellikle React sunucu yapılandırmaları gibi çeşitli ekosistem senaryolarını daha iyi destekliyor
• Kullanıcı koşul bayraklarıyla esnek ve özelleştirilebilir import davranışları oluşturulabiliyor

deno run içinde bare specifier desteği

• deno.json içindeki "imports" alanında tanımlanan alias’lar (bare specifier) ile komut giriş noktası çalıştırılabiliyor
• Geliştirici verimliliği ve modül yönetimi otomasyonu açısından büyük kolaylık sağlıyor

XML, SVG ve benzeri formatlarda kod biçimlendirme iyileştirildi

• deno fmt, .xml, .svg, .mustache gibi çeşitli şablon dosyaları için otomatik biçimlendirme desteği sunuyor

tsconfig.json desteği güçlendirildi

• references, extends, files, include, exclude gibi çeşitli seçeneklerin tanınmasında doğruluk iyileştirildi
• Vue, Svelte, Solid, Qwik gibi modern frontend framework’leriyle daha iyi uyumluluk sağlandı

Node global değişkenleri ve API uyumluluğu artırıldı

• Buffer, global, setImmediate, clearImmediate gibi Node.js global nesneleri artık kullanıcı kodunda da her zaman mevcut
• Daha önce yalnızca npm paketlerine özgü olan bu global’ler artık komut bayrağı olmadan doğrudan kullanılabiliyor
• node:buffer, node:events, node:querystring, node:quic, node:wasm gibi alanlarda %95’in üzerinde uyumluluk sağlandı; kapsamın ileride daha da genişlemesi planlanıyor
• @types/node için varsayılan sürüm de 22.15.14’e güncellendi

Yerel npm paket yönetiminde değişiklik

• npm yerel paket bağlantısı seçeneğinin adı patch yerine links olarak değiştirildi; böylece npm link anlamıyla uyum sağlandı
• Eski seçenek kullanıldığında deprecated uyarısı veriliyor ve daha anlaşılır paket yönetimi mümkün oluyor

LSP ve geliştirici verimliliği iyileştirmeleri

• LSP performans ve özellik iyileştirmelerine ek olarak fetch için Unix/Vsock soket desteği, sunucunun onListen callback’i, Jupyter kernel yönetimi, lint plugin’lerinde yorum okuma ve bench/coverage tablolarında Markdown uyumluluğu gibi çeşitli kolaylıklar sunuluyor
• Windows’ta Ctrl+Close sinyalinin algılanması (Windows SIGHUP) ve bench/coverage metin çıktısının Markdown biçimi gibi alanlarda da yeni iyileştirmeler yapıldı

Topluluğa ve katkıda bulunanlara teşekkür

• Deno 2.4’ün gelişiminde çeşitli topluluk katkıcılarının katılımı ve geri bildirimleri önemli rol oynadı
• Daha fazla içerik ve ayrıntılı değişiklikler için GitHub sürüm sayfasına bakılabilir

Sonuç

• Deno 2.4; bundle, harici dosya importu, gözlemlenebilirlik, izin/güvenlik, uyumluluk ve verimlilik gibi birçok alanda büyük ilerlemeler sunuyor
• Geliştirme akışında ve modern frontend ile Node ekosistemi projelerinde kolay ve güçlü bir entegre geliştirme ortamı deneyimi sağlıyor
• Ek bilgiler, en güncel haberler ve tüm değişiklik geçmişi için resmî belgeler, blog ve GitHub sürüm sayfası incelenebilir

[GN⁺]

Hacker News görüşleri

• Deno’nun konseptini gerçekten çok beğendiğim için, Next.js, Hono ve private package’ları içeren bir monorepo projede Deno.json, JSR, modern import, Deno Deploy vb. şeyleri olabildiğince uygulamaya çalıştığım bir deneyimimi paylaşıyorum. Hono temiz şekilde iyi çalıştı ama Next.js öyle değildi; type ile ilgili sorunlar da ince noktalarda bozulabiliyordu. Dağıtım hedefi seçimi de (Vercel vb.) sorun olmuştu diye hatırlıyorum. Yaşadığım küçük bir sorunu örnek olarak issue linki ile paylaşıyorum. Buna karşılık Bun, Deno kadar temiz hissettirmese de düşünülmesi gereken şey daha azdı ve sadece “çalışıyor” izlenimi veriyordu. Yine de Bun da Vercel’de Bun runtime desteğinin olmaması gibi nedenlerle kusursuz değil

  • Seçilen stack’in hâlâ npm merkezli olmasının, özellikle de private npm package’larının çok olduğu ortamlarda zorluk çıkardığı yönünde bir yorum. Deno tarzı yaklaşımın asıl cazibesinin, baştan Deno ya da ESM dostu bir stack seçmekte olduğunu düşünüyorum. Lume kullanmak ya da Deno Deploy’u hedeflemek iyi bir deneyimdi. (JSR score sayesinde ilginç ve ESM uyumluluğu güçlü kütüphaneleri keşfetmeye de yardımcı oluyor.) Elbette tamamen yeni bir stack ile başlamayı önermek pratikte zor; mevcut Next.js gibi yatırımlar da büyük olduğu için Deno’yu önermek kolay değil. Ama Deno’nun avantajlarının gerçekten ortaya çıktığı yerin, Deno-native ve ESM-native araçlarla sıfırdan başlanan ortamlar olduğunu düşünüyorum. Bu arada Deno’nun npm uyumluluğu giderek iyileşiyor ve 2.4 sürüm notlarında da bununla ilgili geliştirmeler var. Full-stack ortamlarında deno.json yerine package.json öncelikli yaklaşım aslında daha uyumlu olduğundan, uzun vadede deno.json’a geçmeyi düşünseniz bile package json tabanlı yapılandırma da önerilir

  • npm uyumluluk modunda Deno’yu kullanınca beklenmedik şekilde iyi çalıştığı izlenimi oluştu. Bun’un kullanım şekline de oldukça benziyor. package.json bulunan bir dizinde deno install çalıştırırsanız ince bir node_modules oluşturuyor ve deno task something komutuyla package.json’da tanımlı script’leri çalıştırabiliyorsunuz. Ancak Deno’ya özgü yaklaşım çoğu zaman çok vakit alıyor ve bu da sinir bozucu olabiliyor; sonra yeniden node/npm ortamına dönmeye çalışınca işler daha da baş ağrıtıcı hâle geliyor. Sonuç olarak Deno’yu package.json ile birlikte kullanmak daha kolay

  • Başta Deno’ya tamamen yönelmiştim ama ufak tefek sorunlar fazla olduğu için zorlandım. Buna kıyasla Bun pek uğraştırmadan iyi çalışıyor

• İnsanlar Deno’nun node uyumluluğunu küçümsüyor gibi geliyor. compat environment variable’ın yaygınlaşmaya yardımcı olmasını bekliyorum. denon gibi komutların bunu otomatik açması daha da rahat olurdu

  • Benim deneyimimde Deno’nun node uyumluluğu beklentinin altındaydı. Yaklaşık 100~200 satırlık basit bir projeyi Deno’ya taşımak 1 saat kadar sürdü; oysa normalde 5~10 dakikada bitmesi gerekirdi. node’un bazı method’ları desteklenmiyordu ve ilgili dokümantasyon da zayıftı; temel özellikleri bile anlaşılmaz URL’lerden doğrudan indirmek gerekiyordu. Test suite’i taşırken sonunda vazgeçtim. Özellikle CommonJS(CJS)’den ESM’e geçiş düşündüğümden çok daha sancılıydı ve Deno resmi dokümanlarının anlattığı kadar kolay bir geçiş kesinlikle değildi. Tüm kütüphaneyi taşımak mümkün olmadı

  • Eskiden Deno’ya oldukça olumlu bakıyordum ama artık Bun yerine Deno’yu kullanmak için özel bir neden göremiyorum

• Deno’daki son değişiklikler listesinin güzel olduğu söyleniyor. Rastgele script/glue code yazmak için Deno’yu memnuniyetle kullanıyorum (machine learning vb. için python/uv kullanıyorum) ve ileride gRPC desteğiyle bundle komutunu da merakla bekliyorum

• Deno’nun hâlâ FreeBSD’de düzgün çalışmaması şaşırtıcı bulunuyor. Rust tabanlı V8 binding’leri henüz port edilmemiş

  • Modern JavaScript geliştiricileri arasında gerçekte ne kadar FreeBSD kullanıcısı olduğunu merak ediyorum

  • Eskiden Unix’ler arası taşınabilirlik kod temizliğinin bir ölçütüydü, bugünse farklı Unix sistemleri arasındaki uyumluluğun pek vurgulanmaması garip geliyor

  • FreeBSD port’larında kayıtlı görünüyor

  • FreeBSD desteğine büyük çaba harcanmamasını anlamak mümkün

• Deno’nun production’da daha yaygın kullanılmamasının nedenlerinden birinin standartlaşmış bir vulnerability DB eksikliği olduğu görüşü. npm ile %100 uyumluluk bunu bir ölçüde telafi edebilir ama o durumda da popüler deno package’larının çoğu kapsam dışında kalıyor. Temelde merkezi bir package manager’ın olmaması (tasarım gereği) burada zorluk yaratıyor. Bu konuda bir ilerleme olup olmadığı soruluyor

  • Eğer vulnerability DB eksikliği production’da gerçekten büyük bir sorunsa, aynı mantıkla C/C++ da kullanılamaz denebilir. Pratikte C/C++ tarafında güvenlik sorunları için dil bağımsız CVE/GHSA DB’lerine bakılıyor. Ayrıca C’de sık sık dış dosyalar doğrudan vendor edilip sürüm takibi bile yapılmıyor. Bir de deno.lock dosyası var; önem verenler buradaki sürümlere bakarak vulnerability DB kontrolü yapabilir

  • URL’den (GitHub vb.) doğrudan package getirme yapısı Go’da da benzer, dolayısıyla aynı mesele Go için de geçerli

• bundle alt komutunun geri gelmesi hoşuma gitti. Uğraştırıcı geçici çözümlere gerek kalmaması sevindirici

• Bundle işinde Rust tabanlı Rolldown yerine esbuild seçilmesi şaşırtıcı. Rolldown yakında v1 olacak gibi görünüyor

  • esbuild şu anda çok kararlı ve olgun; buna karşılık Rolldown hâlâ hızlı değişiyor, bu yüzden esbuild seçimi daha güvenli

• Deno’nun yönünü gerçekten beğeniyorum ve Node aslında en başta böyle çıkmalıydı diye düşünüyorum. Ama endişem, rakiplerin “hype” dalgasına kapılıp Deno’nun da kendi değişmeden onları takip etmesi

  • Deno’nun kendisi de bir dönem Node.js’in “hype” odaklı rakibi gibi algılanmış olabilir

• Deno hakkında sürekli olumlu şeyler duyuyorum. Bu yüzden js’i bir denesem mi diye düşünmeye başladım

  • Bugünlerdeyse en baştan TS ile başlamak da gayet iyi bir seçenek

• Güvenlik açısından Deno’yu destekliyorum ama resmi sitede kullanıcıya curl mywebsite.com/foo.sh | sh tarzı kurulum önermeleri beni rahatsız etmişti. Elbette herkesin risk toleransı farklı ama en azından dosyayı indirip çalıştırırsanız siz ya da antivirüsünüz onu inceleyebilir. Node/Deno + npm ekosistemi zaten temelde ciddi bir güven gerektiriyor. Resmi rehberde curl | sh dışında npm install -g deno seçeneği de var; npm en azından temel dosya bütünlüğü kontrolleri ve basit zararlı yazılım taramaları sunduğu için nispeten daha güvenli. deno.land sitesi codebase açısından güvenli olsa bile operasyon tarafında %100 güvence vermek zor; bu yüzden curl | sh güvenlik açısından iyi bir uygulama gibi görünmüyor

  • Bu mantığa katılmıyorum. Kurulum script’lerinin çoğu sonuçta aynı yazarın hazırladığı yüzlerce ya da milyonlarca satırlık binary’leri indirip çalıştırıyor. Eğer yazara hiç güvenmeyip sunucunun sadece belirli IP’lere malware dağıtabileceğini varsayacak kadar ileri gidiyorsanız, aynı şeyi binary düzeyinde de yapabilirler; o zaman baştan o projeyi hiç kullanmamak gerekir. curl | sh tartışmasının bu kadar yaygın olmasının nedeni, tekrarlaması kolay bir argüman olması olabilir; oysa asıl güvenlik meselesi milyonlarca satırlık kodun gözden geçirilmesi. Eğer devlet düzeyinde MITM saldırısından endişe edilecek kadar hassassanız, internetteki dış güvene tamamen sırt çevirmek dışında çare kalmaz

  • Yeni kullanıcıların onboarding sürecinde zorluk olduğuna dikkat çekiliyor. npm kullanın deseniz bile önce npm’in kurulu olması gerekiyor; npm’in resmi sitesi ise nvm kurulumunu anlatıyor ve nvm de curl | sh kullanıyor. Yani npm yolu da dolaylı olarak aynı soruna çıkıyor

  • npm install -g deno komutunun curl | sh’dan gerçekten daha güvenli olup olmadığı tartışılırken, asıl noktanın “Bir hacker için npm sunucularına mı yoksa projenin kendi sunucularına mı sızmak daha kolay?” sorusu olduğu belirtiliyor. Eğer projenin kendi sunucularına sızılmadığından eminseniz, curl | sh’nin npm install’dan daha güvensiz olması için bir neden yok. Sonuçta güvenlik açısından bakıldığında iki yöntem de aynı derecede savunmasız olabilir; en uç noktadan bakarsanız sorun internete bağlı olmakta bile görülebilir

  • Deno’nun sandbox uygulamasının 90’lardan kalma bir teknoloji hissi verdiği ve onu kullanmanın başlı başına iyi bir güvenlik alışkanlığı sayılmayacağı eleştirisi

  • Gerçekte curl | sh tarzı kurulumlara yönelik bir saldırının sahada başarıyla uygulanmış somut bir örneği olup olmadığı merak ediliyor