Popüler npm paketlerinin yerini alan en yeni yerleşik Node.js özellikleri

• Son dönemde Node.js, eskiden yalnızca npm paketleriyle mümkün olan işlevleri çalışma zamanına yerleşik olarak ekleyerek hızla gelişiyor
• Bu sayede tedarik zinciri güvenlik risklerini azaltmak, kod taşınabilirliğini artırmak, bağımlılıkları küçültmek ve bakımı sadeleştirmek mümkün hale geliyor; ayrıca üretim ortamında performans ve kararlılığın sağlanmasına katkı sunuyor
• fetch(), WebSocket, node:test gibi global API'ler eklendiğinden, node-fetch, ws, mocha gibi popüler paketler olmadan da geliştirme yapılabiliyor
• Dosya sistemi yeteneklerinin genişlemesiyle glob, rimraf, mkdirp yerine fs.glob(), fs.rm(), fs.mkdir() seçenekleri sunuluyor
• Yardımcı araçlar ve kriptografi API'lerinde crypto.randomUUID(), util.styleText(), atob/btoa gibi özellikler standart olarak geldiği için uuid, chalk gibi paketlere ihtiyaç kalmıyor
• Bazı özellikler (node:sqlite, URLPattern, --env-file, TypeScript çalıştırma vb.) hâlâ deneysel aşamada bulunuyor
• Önemli nokta, Node.js'in kendi evrimi sayesinde yalnızca temel çalışma zamanıyla modern uygulama geliştirmenin mümkün hale gelmesi

---

Node.js'in yerleşik özellikleriyle değiştirilen başlıca npm paketleri

• Node.js bugüne kadar HTTP yardımcıları, dosya sistemi yardımcıları gibi çeşitli npm paketlerine bağımlıydı
• Ancak son sürümlerde (v18~v22) bu işlevleri doğrudan çalışma zamanına entegre etme eğilimi güçleniyor
• Bunun sonucunda paket yönetiminin karmaşıklığı ve güvenlik açığı riski azalıyor

1. node-fetch → Global fetch()

• Node.js 18'den itibaren tarayıcıyla aynı fetch() global fonksiyon olarak sunuluyor
• node-fetch olmadan da HTTP istekleri işlenebiliyor
• v17.5.0'da deneysel olarak sunuldu, v18.0.0'da kararlı hale geldi
• Ancak 18 öncesi sürümlerde hâlâ node-fetch gerekiyor

2. ws → Global WebSocket

• Node.js 21'den itibaren global WebSocket sınıfı ile istemci tarafı WebSocket bağlantıları destekleniyor
  • v21.0.0'da deneysel olarak eklendi, şu ana kadar deneysel aşamada
• Sunucu tarafı WebSocket implementasyonu için hâlâ ws paketi veya ilgili kütüphaneler gerekiyor

3. Test framework'leri → node:test

• Node.js 18'den itibaren mocha, jest vb. yerine geçebilecek yerleşik test çalıştırıcısı node:test sunuluyor
  • v18.0.0'da deneysel olarak tanıtıldı, v20.0.0'da kararlı hale geldi
  • Temel birim testlerinin yazılması ve çalıştırılmasını destekliyor
• Snapshot, mocking, zengin eklenti ekosistemi gibi ihtiyaçlar varsa üçüncü taraf framework'ler hâlâ faydalı
  • Modül düzeyi testler için yeterli olsa da, tam yığın uygulama geliştirmede mevcut framework'lerin avantajları sürüyor

4. sqlite3 / better-sqlite3 → node:sqlite

• Node.js'te SQLite erişimi için deneysel node:sqlite modülü devreye alınıyor
  • Mevcut native binding paketlerindeki derleme sorunlarını ve yükseltme sırasındaki hataları çözmeye yardımcı oluyor
  • Bellek içi veritabanı oluşturma, tablo oluşturma gibi temel işleri destekliyor
• Hâlâ deneysel olduğundan, ileri performans ayarı veya ek özellikler gerekiyorsa topluluk paketleri öneriliyor

5. chalk / kleur → util.styleText()

• Node.js 20.12.0'dan itibaren util.styleText() ile konsol metni biçimlendirme mümkün
  • v22.17.0'da kararlı hale geldi
  • Renk, kalın, altı çizili gibi temel metin stilleri uygulanabiliyor
• Karmaşık temalar, zincirleme sözdizimi, geriye dönük uyumluluk gerekiyorsa chalk vb. kullanılmaya devam edilebilir

6. strip-ansi → util.stripVTControlCharacters()

• ANSI kaçış kodlarını kaldırma işlevi Node.js yerleşik fonksiyonuyla sunuluyor
  • Log'lardaki kontrol karakterlerini güvenli şekilde kaldırabiliyor
• Çoğu kullanım senaryosu native olarak karşılandığı için üçüncü taraf pakete ihtiyaç kalmıyor

7. glob → fs.glob()

• Node.js 22 ile birlikte dosya deseni araması için yerleşik fs.glob() özelliği eklendi
  • v22.0.0'da eklendi, v22.17.0 LTS'te kararlı hale geldi
  • **/*.js gibi glob desenleriyle dosya aranabiliyor
• Eski Node.js sürümleriyle uyumluluk gerekiyorsa glob paketi kullanılmalı

8. rimraf → fs.rm({ recursive: true })

• Dizinleri özyinelemeli silme Node.js native API ile destekleniyor
  • fs.rm() içindeki recursive, force seçenekleriyle uygulanıyor
  • Yaklaşık v12.10.0'dan beri kullanılabiliyor ve mevcut tüm LTS sürümlerinde kararlı
• rimraf paketi olmadan da güvenli dizin silme yapılabiliyor

9. mkdirp → fs.mkdir({ recursive: true })

• Dizinleri özyinelemeli oluşturma fs.mkdir() içindeki recursive seçeneğiyle sunuluyor
  • v10.12.0'dan beri mevcut ve uzun süredir kararlı
• Ayrı bir paket olmadan iç içe dizinler oluşturulabiliyor

10. uuid → crypto.randomUUID()

• Node.js 14.17.0'dan itibaren UUID üretim fonksiyonu crypto.randomUUID() sunuluyor
  • Kriptografi modülünün kararlı bir özelliği olarak yer alıyor
• uuid paketi olmadan güvenli rastgele kimlikler üretilebiliyor

11. base64-js / atob → atob, btoa

• Node.js 20'den itibaren atob, btoa global fonksiyonları sunuluyor
  • Tarayıcıyla aynı Base64 kodlama/kod çözme API'si
  • Mevcut Buffer'a ek bir seçenek sağlıyor
• Polyfill olmadan Base64 işleme mümkün

12. url-pattern → URLPattern

• Node.js 20'den itibaren global URLPattern API'si deneysel olarak sunuluyor
  • Route eşleştirme, yol parametresi çıkarma gibi işlevleri destekliyor
  • Hâlâ deneysel aşamada ve kararlı hale gelmesi gerekiyor
• URL desen eşleştirme standart Web API ile yapılabiliyor

13. dotenv → --env-file bayrağı

• Node.js 20.10.0'dan itibaren --env-file bayrağıyla ortam değişkeni yükleme destekleniyor
  • Çalıştırma sırasında .env dosyası doğrudan yüklenebiliyor
  • Hâlâ deneysel aşamada
• Değişken genişletme, çoklu env dosyası gibi ileri özellikler için dotenv paketi gerekiyor

14. event-target-shim → EventTarget

• Node.js 15.0.0'dan itibaren Web standardı EventTarget global olarak sunuluyor
  • v15.4.0'da kararlı hale geldi
  • Tarayıcıyla aynı olay işleme modelini destekliyor
• EventEmitter için bir alternatif olarak kullanılabiliyor

15. tsc → Node.js ile TypeScript çalıştırma

• Node.js 21'den itibaren --experimental-strip-types bayrağıyla .ts dosyalarını doğrudan çalıştırmak mümkün
  • Yalnızca tipleri kaldırıyor, tam tip denetimini desteklemiyor
  • Hâlâ deneysel aşamada
• Üretim derlemesi, statik tip denetimi, bildirim dosyası üretimi, tam tip denetimi için tsc hâlâ gerekli

Sonuç

• Node.js'in ilerleme yönü, harici paket bağımlılığını azaltmak ve platformun kendi bütünlüğünü artırmak
• Güncel LTS sürümünde (v22) birçok npm paketi zaten gereksiz hale gelmiş durumda;
  bu da güvenlik, performans ve bakım kolaylığı açısından büyük bir iyileşme anlamına geliyor
• Kurumsal operasyon ortamlarında bu değişimleri gerçek zamanlı izlemek için N|Solid gibi çözümler kullanılıyor
  • Yerleşik özelliklerin (fetch, node:test, crypto.randomUUID() vb.) gerçek iş yükü performans analizi
  • N|Sentinel yapay zeka ajanı, kullanım izleme ve kod düzeyinde optimizasyon önerileri sunuyor

[nemorize]

Runtime’ın sunduğu API’ler giderek artıyor..
Özellikle ağ API’leri, URL, b64 gibi string işleme API’leri vb...

Bu resmen... PH..

[carnoxen]

Görünüşe göre UUID v7 için henüz erken.

[click]

Bence db driver, diğer temel kütüphanelere girmesi gereken işlevlerden farklı bir açıdan değerlendirilmeli; peki bun ve diğerleri neden sqlite sürücüsünü çalışma zamanına gömmeye çalışıyor?
Acaba Python bunu gömülü sunduğu için mi?

Bence sqlite işlevini gömmektense db driver arayüzü için bir standart oluşturmak daha önemli.
Sürücüye göre arayüzler farklı olduğu için, birden çok türde db desteği sağlamak orm kullanmadan zorlaşmıyor mu?

[aer0700]

Muhtemelen kişisel blog gibi küçük ölçekli servislerde yalnızca sqlite çoğu zaman yeterli olduğu için eklemişlerdir diye düşünüyorum. Olursa kullanışlı oluyor.

[tujuc]

Bence sqlite, arayüzü en basit olan ve referans almak için en uygun örnek olduğu için eklenmiş gibi görünüyor.

Ayrıca bahsettiğiniz DB Driver arayüz standardını neden oluşturmak gerektiğini de bilmiyorum. Benzer bir şeyi PHP’de görmüş gibiyim diye hatırlıyorum.

ORM’nin işleyemediği karmaşık sorgular için hâlâ RAW sorgular kullanılıyor...
Görünüşe göre farklı türde DB’leri sık kullanıyorsunuz... Bir kütüphane yapmayı denesenize? :)

[click]

python, java, c#, go vb. gibi ortamlarda runtime’ın db driver arayüzü standardı oluşturması oldukça yaygındır.
Ama Node tarafında, aynı sqlite hedefi için olan driver’lar arasında bile statement çalıştırma execute() ya da exec() olarak değiştiği için, sadece driver’ı değiştirmek bile belli ölçüde kod düzenlemesi gerektiriyor.

Çok sık olan bir durum değil ama db değiştirmek gerektiğinde de bu rahatsız edici oluyor.
Örneğin mysql kullanırken Oracle’ın yaptıkları hoşunuza gitmez ya da postgresql uzantıları arasında mutlaka gerekli olan bir şey vardır da postgresql’e geçeceğinizi varsayarsak,
jdbc gibi standart bir arayüz varsa sadece SQL’i doğrulamak yeterli oluyor ama Node ekosisteminde db çağrı mantığını baştan aşağı yeniden yazmak gibi bir yan etkisi var.

+Bir kütüphane yazmayı önermiştiniz ama ortak bir arayüz standardı olduğunda kütüphane geliştirmek daha kolay oluyor.
Şirket Java kullanıyor; şirket içi özel framework’te mysql, db2, oracle, mssql desteği gerektiği için, veritabanına özel adapter’ların bakımında jdbc standardının faydasını çok gördüm.