Node.js 26.9, FFI'ı Varsayılan Olarak Açtı; Bench, Web Workers ve VFS Hâlâ Flag Arkasında

Node.js 26.9.0 dün Current sürümü olarak yayınlandı. Sürüm notları, Node'un bünyesine katmaya karar verdiği npm paketlerinin listesi gibi okunuyor: bir benchmark runner, bir foreign function interface, tarayıcı tarzı Web Workers ve artık modül yükleyicilere bağlanan bir sanal dosya sistemi. Ancak 26.9.0 API dokümantasyonuyla birlikte okuyunca, bunlardan yalnızca birinin varsayılan olarak açık olduğunu görüyorsunuz. O da en keskin kenarlara sahip olanı: node:ffi.

Neler geldi#

• node:ffi varsayılan olarak etkin. Modül v26.1.0'da gelmişti ve hâlâ Stability 1, Experimental olarak işaretli.
• node:bench, reporter'lara ve açık bir createRunner API'sine sahip yeni bir modül ve CLI benchmark runner. Dokümantasyon onu 1.0, Early Development olarak işaretliyor ve aynı sürümdeki bir commit onu --experimental-bench arkasına aldı.
• Web Workers: node:worker_threads üzerine kurulu, büyük ölçüde tarayıcı uyumlu global bir Worker; Web Platform Tests de eklendi. --experimental-web-worker gerektiriyor.
• v26.4.0'dan beri --experimental-vfs arkasında olan node:vfs, mount() kazanıyor. Böylece sanal dosyalara node:fs, require() ve import üzerinden erişilebiliyor.
• Daha küçük değişiklikler: genel bir MAC API'si, OpenSSL provider'larından keşfedilen cipher ve hash'ler, deneysel bir DTLS API'si, perf_hooks içinde Histogram meanCI ile CBOR export/import desteği ve embedder'ların snapshot olmadan builtin code cache sağlayabilmesi.

Varsayılan olarak açık FFI, neyi review ettiğinizi değiştiriyor#

FFI dokümantasyonu API'nin güvensiz olduğunu açıkça söylüyor. Geçersiz pointer'lar, yanlış sembol imzaları ya da serbest bırakılmış belleğe erişmek "can crash the process or corrupt memory" ve modül pointer geçerliliğini, sahipliğini ya da native nesne yaşam sürelerini takip etmiyor.

Bir reviewer olarak benim önemsediğim kısım görünürlük. Bir bağımlılıktan native kod çağırmak eskiden iz bırakırdı: derlenmiş bir addon, bir build adımı, tarball içinde prebuilt binary'ler. node:ffi'ın onu içeren build'lerde varsayılan olarak kullanılabilir olmasıyla, sıradan bir .js dosyası bir shared library'yi dlopen ile açıp sembollerini çağırabiliyor. O kütüphane makinede zaten varsa, kurulumda hiçbir şeyin farklı görünmesi gerekmiyor.

Dokümante edilmiş iki kontrol var:

# Turn the module off where you don't need it
node --no-experimental-ffi server.js

# Under the Permission Model, FFI throws ERR_ACCESS_DENIED unless allowed
node --permission --allow-ffi app.js

node:bench bir runner, hüküm değil#

API küçük: suite(), bench() ve ölçülen işin etrafında start() ile end(operations) çağırdığınız bir context. CLI'dan node --experimental-bench --bench 'benchmarks/**/*.js' dosyaları sırayla, varsayılan olarak her birini kendi child process'inde çalıştırıyor; bir JSON reporter da mevcut.

Hoşuma giden, dışarıda bıraktıkları. Bench dokümantasyonu, bir baseline belirlemediğini ya da pass/fail karşılaştırması üretmediğini söylüyor. Ham örnekleri, kararlı benchmark kimliklerini, parametreleri ve tag'leri sunuyor; karşılaştırma politikasını üst seviye araçlara bırakıyor. Quorate'te kullandığım ayrım da tam olarak bu: ham sinyali bir katmanda topla, deterministik kapıları başka bir katmanda uygula. "Measurement integrity" bölümü tek başına okunmaya değer; istatistiksel olarak tutarlı bir sonucun, benchmark'ın ölçmek istediğiniz işi ölçtüğünü kanıtlamadığına dair uyarı da buna dahil.

Bir ekip için, erken geliştirme aşamasındaki ve flag arkasındaki bir modül uğruna mevcut bir benchmark kütüphanesini söküp atmazdım. Yeni micro-benchmark'ları ise ileride kolayca taşınabilecek bir yapıda yazardım.

Web Workers ve VFS: faydalı, ama hâlâ opt-in#

Web Worker global'i, hem tarayıcıda hem Node'da çalışması amaçlanan kod için önemli; React ya da Next.js front end'lerin Node servisleriyle yan yana durduğu yapılarda bu oldukça yaygın. Sınırlar dokümante edilmiş: script'ler yalnızca file:, data: ve blob: URL'lerinden yükleniyor, SharedWorker yok ve workerData, kaynak limitleri ya da özel bir env gerektiğinde dokümantasyon sizi hâlâ worker_threads'e yönlendiriyor.

VFS dokümantasyonu modülü testler, fixture'lar ve gömülü asset'ler için konumlandırıyor; eşlik eden bir commit de single executable application asset'lerini bir VFS olarak mount ediyor. Mount noktaları ayrılmış bir namespace'te yaşıyor, dolayısıyla sanal yollar hiçbir zaman gerçek yolları gölgelemiyor. VFS dokümantasyonu ayrıca bunun bir sandbox, izin sistemi ya da erişim kontrol mekanizması olmadığını açıkça belirtiyor. Herhangi bir şeyi izole etmek için kullanmayın.

Bu neden Current'a ait#

Buradaki her öne çıkan API, 26.9.0 dokümantasyonunda experimental olarak işaretli ve node:bench en erken aşamada. Current hattı tam da bunun için var: yayınla, geri bildirim topla, şeklini değiştir. Küçük commit'ler bile davranış değişiklikleri taşıyor. Örneğin fs içindeki ** glob'ları, symlink'leri takip etmiyorsanız artık symlink'lerin içine inmiyor. Production bir LTS hattında kalmalı ve 26.x deney yapılacak yer olarak görülmeli.

Bu konuda ne yapıyorum#

• Dockerfile'larda ve systemd unit'lerinde major tag üzerinde kaymak yerine Node sürümlerini tam olarak sabitliyorum; böylece bir minor sürüm sessizce bir yeteneği açamıyor.
• Native çağrı yapması için bir nedeni olmayan her 26.x servisine --no-experimental-ffi ekliyorum.
• Bağımlılık diff'lerini ve AI tarafından üretilmiş patch'leri review ederken aradığım kalıplara, child_process ve dinamik require()'ın yanına node:ffi'ı da ekliyorum.
• Bastığı herhangi bir sayıya güvenmeden önce node:bench'i bir branch'te deniyor, JSON çıktısını kendi eşik değerlerimizi içeren küçük bir script'e besliyorum.