Bun 1.2 yayımlandı: Node.js uyumluluğu, S3 ve Postgres yerleşik

(bun.sh)

1 puan yazan GN⁺ 2025-01-25 | 1 yorum | WhatsApp'ta paylaş

Bun 1.2, full-stack JavaScript/TypeScript geliştirme aracı olmayı hedefleyen; Node.js uyumluluğunu ve runtime, bundler, test ile paket yöneticisini birlikte genişleten büyük bir sürüm
Her değişiklikte Node.js test paketini çalıştırarak uyumluluk doğrulamasını güçlendirdi ve node:http2, node:dgram, node:cluster, node:zlib, node:v8 desteği eklendi
Yeni yerleşik API’ler Bun.s3 ve Bun.sql, S3 uyumlu nesne depolamayı ve Postgres erişimini runtime içine taşıyarak harici istemci bağımlılığını azaltıyor
Paket yöneticisi varsayılan lockfile’ı ikili bun.lockb yerine JSONC tabanlı bun.lock olarak değiştiriyor; ayrıca .npmrc, bun publish, bun patch, bun outdated, bun run --filter ekleniyor
bun run çalışma dizini, Bun.build() hata işleme biçimi, server.stop() dönüş değeri, bun -p, varsayılan sourcemap ayarı değiştiği için mevcut projelerin geçiş etkisini kontrol etmesi gerekiyor

Node.js uyumluluğu güçlendirildi

Bun 1.2, her Bun değişikliğinde Node.js test paketini çalıştıracak şekilde uyumluluk iyileştirme sürecini değiştirdi
- Daha önce hatalar ağırlıklı olarak GitHub issue’ları veya npm paketlerinin çalışmamasına dair raporlar üzerinden düzeltiliyordu; ancak bu yöntem, büyük refactor’ları zorlaştıran bir “köstebek vurma” yaklaşımına yakındı
- Node.js deposundaki binlerce test dosyası Bun’a taşındı ve her commit’te bu testler çalıştırılarak uyumluluk doğrulanıyor
Node.js testlerinde bazen iç uygulama ayrıntıları ve tam hata mesajları doğrulandığı için, Bun bazı testlerde iç binding’leri kendi stub’larıyla değiştirdi veya doğrulamayı name ve code odaklı olacak şekilde uyarladı
- Bun, mümkün olduğunca Node.js’in hata mesajlarını eşleştirmeye çalışıyor; ancak name ve code aynıysa, bazı durumlarda daha faydalı mesajlar da sunabiliyor
Yeni desteklenen Node.js modülleri ve özellikleri
- node:http2: HTTP/2 sunucusu oluşturma desteği, gRPC sunucuları için de gerekli
- node:dgram: UDP soketlerinde bind/connect desteği
- node:cluster: Birden fazla Bun instance’ı çalıştırarak işleri çoklu CPU çekirdeğine dağıtma
- node:zlib: JavaScript uygulaması native kodla yeniden yazıldı ve Bun 1.1’den 2 kat daha hızlı hale geldi
- node:v8: getHeapSnapshot, writeHeapSnapshot ile Bun heap’i Chrome DevTools’ta incelenebiliyor
node:http2 sunucusu Bun 1.2’de Node.js’ten 2 kat daha hızlı
express, node:http uyumluluğundaki iyileştirmeler ve Bun HTTP sunucusu optimizasyonları sayesinde HTTP isteklerini Node.js’ten en fazla 3 kat daha hızlı işliyor
V8 C++ API kullanan C++ eklenti desteği de eklendi
- Node.js V8, Bun ise JavaScriptCore kullandığı için uygulama zorluk seviyesi yüksek
- Bun, JavaScriptCore üzerinde V8’in açık C++ API’sini uygulayarak cpu-features gibi paketlerin çalışmasını sağlıyor
- V8 C++ API desteği karmaşık olduğundan çoğu pakette hâlâ eksik özellikler olabilir; node-canvas@v2 ve node-sqlite3 gibi paketler için destek geliştirilmeye devam ediyor

Yerleşik S3 API’si `Bun.s3`

Bun 1.2, S3 uyumlu nesne depolamayı yönetmek için yerleşik API Bun.s3 ekliyor
- Amazon S3, Google Cloud Storage, Cloudflare R2 gibi S3 API’sini uygulayan servislerle kullanılabiliyor
- Dosya okuma, yazma ve silme işlemleri Web standardı Blob ile uyumlu bir API üzerinden yapılıyor
s3.file(), S3 dosyasına yönelik gecikmeli bir referans döndürüyor; text(), json(), arrayBuffer(), stream() gibi Bun File API’siyle aynı şekilde kullanılabiliyor
Bun’un S3 istemcisi JavaScript ile değil, native kodla yazıldı
- Node.js’te @aws-sdk/client-s3 kullanımıyla karşılaştırıldığında, S3 bucket dosyası indirme işlemi 5 kat daha hızlı
Yazma işlevleri için write() ve writer() sunuluyor
- write(), string, Uint8Array, Blob, Response gibi verileri yükleyebiliyor
- writer(), büyük dosyalar için multipart upload gerçekleştiriyor
presign(), belirli bir dosyanın yüklenmesine izin veren presigned URL üretiyor
- Kullanıcıya kimlik bilgilerini göstermeden veya bucket’a gereksiz erişim yetkisi vermeden doğrudan S3’e yükleme yaptırılabiliyor
Bun.serve() ile birlikte kullanıldığında, new Response(s3.file(...)), sunucunun S3 dosyasını indirip yeniden göndermesi yerine presigned URL’ye yönlendiriyor
- Bellek, zaman ve sunucunun dosya indirme bant genişliği maliyetini azaltıyor
s3:// URL’leri Bun.file() ve fetch() içinde de kullanılabiliyor
- fetch("s3://...") ile yükleme, indirme ve silme yapılabiliyor
- Varsayılan S3Client, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY gibi ortam değişkenleriyle yapılandırılıyor

Yerleşik Postgres istemcisi `Bun.sql`

Bun 1.2, Postgres destekleyen yerleşik SQL istemcisi Bun.sql ekliyor
- Bun daha önce yerleşik bir SQLite istemcisi sunuyordu; bu sürümle SQL veritabanı desteğinin kapsamı genişliyor
- MySQL desteği ekleyen bir pull request de bulunuyor
Bun.sql, SQL çalıştırmak için tagged-template literal kullanıyor
- JavaScript değerleri SQL parametresi olarak aktarılabiliyor
- String escape ve prepared statement’ları otomatik kullanarak SQL injection’ı önlüyor
Sonuçlar, sütun adlarını anahtar olarak kullanan nesne dizileri halinde döndürülüyor
Native kod uygulaması ve çeşitli optimizasyonlar kullanılıyor
- otomatik prepared statement
- query pipelining
- binary wire protocol
- connection pooling
- yapı önbellekleme
Node.js’te popüler Postgres istemcilerini kullanmaya kıyasla satır okuma performansı en fazla %50 daha hızlı
API, postgres.js’den ilham alıyor ve mevcut kodun Bun’un yerleşik SQL istemcisine kolay taşınabilmesi için tasarlandı

Paket yöneticisi değişiklikleri

Bun 1.2, varsayılan lockfile'ı ikili bun.lockb yerine metin tabanlı bun.lock olarak değiştiriyor
- bun.lockb, bun install komutunun npm'den neredeyse 30 kat daha hızlı olmasına yardımcı oldu, ancak GitHub'da içeriğini görüntülemek zordu ve pull request incelemesi ile merge conflict çözümü zorluydu
- Dependabot gibi araçlar için de lockfile'ı okumak zordu
bun.lock bir JSONC dosyasıdır
- Yorumları ve trailing comma'yı destekler
- Pull request diff'lerini incelemek kolaylaşır ve trailing comma sayesinde merge conflict olasılığı azalır
Yeni projeler bun.lock oluşturur
- Mevcut bun.lockb projeleri otomatik migrasyon olmadan ikili lockfile desteğini sürdürür
- bun.lockb uzun vadede desteklenecek ve bun add, bun update ile güncellenmeye devam edecek
- bun install --save-text-lockfile ile yeni metin tabanlı lockfile'a geçiş yapılabilir
Metin tabanlı lockfile'a geçişten sonra da bun install, Bun 1.1'e göre %30 daha hızlı
package.json içinde yorumlar ve trailing comma kullanılabilir
- require() ve import() da bu tür package.json dosyalarını okuyabilir
- Bunun JavaScript ekosisteminin tamamında yaygın olarak desteklenen bir özellik olmadığı, bu yüzden “at your own risk” kullanılması gerektiği belirtiliyor
.npmrc desteği eklendi
- Proje kökü ve home dizinindeki .npmrc dosyaları okunur
- Registry, scoped package ve private registry kimlik doğrulama ayarları için kullanılabilir
Yeni paket yöneticisi komutları ve seçenekleri
- bun run --filter: Birden fazla workspace'te aynı script'i eşzamanlı çalıştırır
- bun outdated: Güncel olmayan bağımlılıkları kontrol eder
- bun publish: npm publish yerine geçer; .npmrc kimlik doğrulaması, tarball packing, OTP ve package.json edge case'lerini destekler
- bun patch: Bağımlılıklardaki değişiklikleri patches/ içindeki .patch dosyalarına kaydeder ve bun install sırasında otomatik uygular
- --omit=dev|optional|peer: Kurulumda dev, optional ve peer bağımlılıklarını hariç tutar
- CA sertifikaları bunfig.toml, CLI flag'leri ve .npmrc üzerinden yapılandırılabilir
- bundleDependencies ve bun add için package.json girintilemesini koruma desteği de eklendi

Test runner iyileştirmeleri

bun test, JUnit XML reporter desteği sunuyor
- bun test --reporter=junit --reporter-outfile=junit.xml ile test sonuçları Jenkins, CircleCI, GitLab CI gibi CI/CD araçlarına iletilebilir
- JUnit raporlaması bunfig.toml içinden de yapılandırılabilir
Kod kapsamı için LCOV reporter eklendi
- bun test --coverage --coverage-reporter=lcov ile coverage/lcov.info oluşturulur
- --coverage-dir ile çıktı dizini değiştirilebilir
expect().toMatchInlineSnapshot() ile inline snapshot desteği geldi
- bun test -u veya --update-snapshots ile snapshot'lar test dosyasının içinde güncellenir
- toThrowErrorMatchingSnapshot() ve toThrowErrorMatchingInlineSnapshot() da kullanılabilir
test.only() artık --only flag'i olmadan da çalışıyor
expect() API'sine Jest, Vitest ve jest-extended benzeri matcher'lar eklendi
- toContainValue(), toContainKey(), toHaveReturned() ailesi
- İkinci argüman olarak özel hata mesajı verilebilir
jest.setTimeout() ve setDefaultTimeout() ile mevcut scope veya modül için varsayılan test timeout'u değiştirilebilir

Bundler ve build özellikleri

Bun 1.2, HTML import desteği sunuyor
- Bir HTML dosyası Bun.serve içindeki static seçeneğine verildiğinde, HTML içindeki <script> ve <link> öğelerini otomatik bundle eder ve statik route olarak sunar
bun build --compile, cross-compilation desteği sunuyor
- Linux'ta Windows veya macOS ikilileri üretilebilir, tersi de mümkündür
- Windows build'lerinde ikon ayarlama ve konsol penceresini gizleme seçenekleri kullanılabilir
bun build --bytecode, bytecode cache oluşturur
- eslint gibi uygulamaların başlangıç süresini 2 kat hızlandırabilir
- .jsc dosyası ilgili .js dosyasının bytecode cache'ini içerir ve çalıştırma için iki dosya da gereklidir
- Bytecode cache, kaynak koda göre 8 kat daha büyük olabilir; bu da başlangıç süresi iyileşmesi karşılığında daha fazla disk alanı kullanıldığı anlamına gelir
bun build --format=cjs ile CommonJS çıktı formatı belirtilebilir
- Daha önce yalnızca ESM destekleniyordu
- Eski Node.js sürümlerini hedefleyen kütüphane veya uygulama geliştirmek kolaylaşıyor
CommonJS algılama iyileştirildi
- Dosya belirsiz olduğunda, üstteki "use strict" yönergesi CommonJS için son heuristik olarak kullanılır
- require.main === module, import ifadeleriyle birlikte kullanılabilmesi için import.meta.main olarak yeniden yazılır
Plugin API'sine onBeforeParse() hook'u eklendi
- Bunun JavaScript yerine bir N-API addon olarak uygulanması gerekir
- Rust, C/C++, Zig gibi derlenen dillerde parse öncesinde kaynak kod neredeyse sıfır overhead ile işlenebilir
- Plugin ve framework yazarlarına yönelik ileri seviye bir API'dir
Build seçenekleri de genişletildi
- --env="PUBLIC_*" ile ortam değişkenleri bundle içine enjekte edilir
- --drop=console gibi kullanım biçimleriyle fonksiyon çağrıları kaldırılabilir
- Banner/footer ekleme
- Bun.embeddedFiles() ile standalone executable içine gömülü dosyaların listesi görülebilir
- --ignore-dce-annotations ile hatalı dead-code elimination annotation'ları yok sayılabilir
- --packages=external ile paket bağımlılıklarının bundle içine dahil edilmemesi sağlanabilir

CSS bundling

Bun 1.2, yeni bir CSS parser ve bundler uyguluyor
- LightningCSS'in çalışmalarından türetildi ve Rust'tan Zig'e yeniden yazılarak Bun'ın JavaScript/TypeScript parser'ı, bundler'ı ve runtime'ı ile entegre edildi
bun build ./index.css ile birden fazla CSS dosyası ile @import, url, @font-face referansları tek bir CSS dosyasında birleştirilebilir
JavaScript ve TypeScript kodunda .css dosyaları import edilebilir
- JavaScript module graph'ında import edilen CSS ve @import kuralları, entrypoint bazında tek bir CSS dosyasına düzleştirilir
Bun.build() API'si ile CSS ve JavaScript aynı API üzerinden bundle edilebilir

Bun çalışma zamanı API eklemeleri

Bun.serve(), static özelliğiyle statik rotaları destekliyor
- Yolu anahtar, Response nesnesini değer olarak alıyor
- Statik rotalar, fetch() işleyicisinde doğrudan ele almaya kıyasla %40'a kadar daha hızlı
- response body, header ve status code bellekte önbelleğe alındığı için JavaScript allocation ve garbage collection olmuyor
- Statik rotalar server.reload() ile yeniden yüklenebiliyor
Bun.udpSocket(), Bun API tarzında bir UDP soketi sunuyor
- node:dgram da destekleniyor, ancak Bun.udpSocket() mevcut Bun.listen()a benzer modern bir API
- Tek bir syscall ile birden çok UDP datagramı gönderebiliyor ve OS backpressure durumuna yanıt veriyor
Bun.file(), delete(), unlink(), stat() desteği sunuyor
- stat(), Node.js fs.stat() içindeki Stats nesnesiyle aynı biçimde metadata döndürüyor
- Aynı API S3 dosyaları için de kullanılabiliyor
Bun.color(), renk ayrıştırma, normalleştirme ve dönüştürme sağlıyor
- CSS, ANSI color code, RGB, HSL vb. destekleniyor
dns.prefetch(), başlangıçta DNS cache'i ısıtmak için DNS kayıtlarını önceden getirebiliyor
- dns.getCacheStats() ile DNS cache durumu kontrol edilebiliyor
Diğer yardımcı araçlar
- Bun.inspect.table(): console.table benzeri tablo biçimli bir string döndürüyor
- Bun.randomUUIDv7(): sıralama ve veritabanları için uygun monotonic UUID v7 üretiyor

SQLite istemcisi iyileştirmeleri

Bun'un yerleşik SQLite istemcisi, query.as(Class) ile sorgu sonuçlarını sınıf örneklerine eşleyebiliyor
- getter, setter ve method eklenebiliyor
- Performans nedeniyle class constructor, default initializer ve private field desteklenmiyor
- İlişki yönetimi veya SQL üretimi yapmadığı için bir ORM değil
query.iterate(), satırların tümünü bir anda belleğe yüklemeden iterator ile işliyor
- Sorgu nesnesinin kendisi de for döngüsüyle dolaşılabiliyor
strict seçeneği açıldığında sorgu parametrelerinde $, @, : prefix'i atlanabiliyor
- Parametre eksikse hata fırlatıyor
db.run() sonucunda değişen satır sayısı ve son eklenen row ID görülebiliyor
- changes
- lastInsertRowid
safeIntegers seçeneği, 64 bit tamsayıları kesilmiş number yerine BigInt olarak döndürüyor
- Veritabanı düzeyinde veya sorgu düzeyinde ayarlanabiliyor
JavaScript using sözdizimiyle statement ve database, scope sonunda otomatik olarak kapatılabiliyor

JavaScript'ten C derleme ve çalıştırma

Bun 1.2, JavaScript'ten C derleyip çalıştırmak için deneysel destek ekliyor
- bun:ffi içindeki cc() API'si kullanılıyor
- Ayrı bir build step olmadan JavaScript'ten C system library kullanmayı sağlayan bir yaklaşım
Bun, yerleşik olarak tinycc içeriyor
- gcc veya clangdan farklı olarak basit C kodunu milisaniyeler içinde derleyebiliyor
- Gerektiğinde C kodu derlenip çalıştırılabiliyor
N-API kullanan C kodu için de destek sunuluyor
- node-gyp build aşaması olmadan, yalnızca Bun ile çalışıyor

musl ve Alpine Linux desteği

Bun 1.2, glibc yerine musl libc kullanan Linux dağıtımları için Bun derlemesi ekliyor
- Alpine Linux gibi ortamlarda kullanılabiliyor
- Linux x64 ve aarch64 destekleniyor
Docker'da oven/bun:alpine imajı kullanılabiliyor
musl daha küçük container imajları sağlasa da Bun'un glibc sürümüne göre biraz daha yavaş olma eğiliminde
- Özel bir neden yoksa glibc kullanılması öneriliyor

JavaScript dil özellikleri

import attributes desteği eklendi
- import json from "./package.json" with { type: "json" } gibi JSON, text, TOML vb. türleri belirterek import etmek mümkün
- Dinamik import() içinde de kullanılabiliyor
using ve await using destekleniyor
- Scope dışına çıkıldığında [Symbol.dispose] veya [Symbol.asyncDispose] çağrılarak kaynaklar otomatik temizleniyor
- Bun.spawn(), Bun.serve(), Bun.connect(), Bun.listen(), bun:sqlite gibi çeşitli Bun API'lerinde destekleniyor
Promise ile ilgili yeni API'ler
- Promise.withResolvers(): promise, resolve, reject öğelerini tek seferde oluşturuyor
- Promise.try(): senkron veya asenkron fonksiyonu bir promise içine sarıyor
Hata ve byte array API'leri
- Error.isError(): prototype chain manipülasyonu veya node:vm cross-realm durumlarında bile bunun Error olup olmadığını daha doğru saptıyor
- Uint8Array.toBase64() / Uint8Array.fromBase64()
- Uint8Array.toHex() / Uint8Array.fromHex()
iterator helper eklendi
- map, flatMap, filter, take, drop, reduce, toArray, forEach, find
Float16Array destekleniyor
- 16 bit floating-point diziler, 32 bit'e göre daha düşük hassasiyetli ama daha bellek verimli

Web API eklemeleri

TextDecoderStream ve TextEncoderStream destekleniyor
- TextDecoder ve TextEncoderın streaming sürümleri
- Bun'da TextEncoderStream, Node.js'ten 30 kata kadar daha hızlı
TextDecoder için stream seçeneği destekleniyor
- chunk, tam bir UTF-8 code point olmasa bile daha büyük bir akışın parçası olarak işlenebiliyor
bytes() yöntemi eklendi
- Response, Blob, Bun.file() vb. üzerinde stream verisini Uint8Array olarak döndürüyor
- Mevcut arrayBuffer() ardından Uint8Array oluşturma sürecini azaltıyor
streaming fetch() upload destekleniyor
- Büyük dosyaları veya content length'i önceden bilinmeyen veri akışlarını yüklemek için kullanışlı
console.group() ve console.groupEnd() uygulandı
URL.createObjectURL() destekleniyor
- Blob içinden URL oluşturulup fetch(), Worker, import() için kullanılabiliyor
- Worker script'leri de Bun transpiler'dan geçtiği için TypeScript sözdizimi kullanılabiliyor
AbortSignal.any(), birden fazla AbortSignali birleştirerek biri abort edildiğinde üst signalin de abort edilmesini sağlıyor

Davranış değişiklikleri ve geçişte dikkat edilmesi gerekenler

bun run için çalışma dizini değişti
- Önceden shell’in geçerli çalışma dizini kullanılıyordu
- Bun 1.2’de package.json dosyasının üst dizini, script çalışma dizini olarak kullanılıyor
- Bu değişiklik, npm ve yarn davranışıyla uyum sağlamak için yapıldı
bun test, testler arasındaki uncaught error veya rejection durumlarını artık başarısızlık olarak raporluyor
- Önceden bu tür hatalar test başarısızlığı olarak işlenmeyebiliyordu
server.stop() artık Promise<void> döndürüyor
- devam eden HTTP bağlantıları kapanana kadar beklenebiliyor
Bun.build(), başarısız olduğunda hataları resolve edilen sonucun logs alanına koymak yerine reject ediyor
- Eski davranış gerekiyorsa throw: false ayarlanabilir
bun -p, Node.js ile uyumlu olacak şekilde artık bun --print için bir alias oldu
- Önceden bun --port alias’ıydı
bun build --sourcemap için varsayılan değer, inline source map’ten linked source map’e değişti
- Eski davranış gerekiyorsa --sourcemap=inline kullanın

Performans iyileştirmeleri

Bun 1.2, çeşitli yürütme yollarında performans iyileştirmeleri içeriyor
- node:http2: 2 kat daha hızlı
- node:http üzerinden S3 yüklemeleri: 5 kat daha hızlı
- path.resolve(): 30 kat daha hızlı
- fetch() DNS resolution: 2 kat daha hızlı
- bun --hot: bellek kullanımı 2 kat azaldı
- macOS fs.readdirSync(): küçük dizinleri okuma %5 daha hızlı
- String.at(): %44 daha hızlı
- büyük string girdilerinde atob(): 8 kata kadar daha hızlı
- fetch() gzip verisi açma: %30 daha hızlı
- büyük girdilerde Buffer.from(string, "base64"): 6 ila 30 kat daha hızlı
- büyük string girdilerinde JSON.parse(): 2 ila 4 kat daha hızlı, object girdilerinde %6 daha hızlı
- bazı Bun.serve() uygulamalarında throughput: 2 kata kadar arttı
- Error.captureStackTrace(): 9 kat daha hızlı
- küçük dosyalarda fs.readFile(): %10’a kadar daha hızlı
- string argümanlarıyla console.log(): %50 daha hızlı
Windows’ta JavaScriptCore’un JIT’i etkinleştirildi
- Önceden JIT yalnızca macOS ve Linux’ta kullanılabiliyordu
- Windows’ta JavaScript artık genel olarak daha hızlı çalışıyor
- Örneğin Object.entries() %20, Array.map() ise %50 daha hızlı

Kurulum ve yükseltme

Yeni kurulum komutları
- curl -fsSL https://bun.sh/install | bash
- powershell -c "irm bun.sh/install.ps1 | iex"
- npm install -g bun
- brew tap oven-sh/bun ardından brew install bun
- docker pull oven/bun
Halihazırda kurulu Bun, bun upgrade ile yükseltilebilir

1 yorum

GN⁺ 2025-01-25

Hacker News görüşleri

Üçüncü taraf veritabanlarını ve harici S3 kütüphanelerini neden core/standart kütüphaneye koyduklarını anlamıyorum
Böyle şeyler için isteğe bağlı kütüphaneler daha iyi olmaz mı; böyle bir runtime, standart kütüphaneye ne koyacağını çok dikkatli seçmeli
Şimdiden her şeyi içine atan, mutfak lavabosu gibi bir proje hissi veriyor
- Bence Bun’ın ilgi görmesinin nedenlerinden biri de tam bu yaklaşım
  Piller dahil yaklaşımı pek çok yerde popüler ve tercih edilen bir yol
  TypeScript yapılandırması zor; Webpack, S3, Postgres, Jest vb. de öyle, bu yüzden sadeleştirilmiş dosya ve stream erişimi de epey ilginç
  Dağıtık dağıtım sağlayıcılarının nasıl ortaya çıkacağını izlemek yeterli gibi
- Bildiğim kadarıyla Bun VC yatırımı aldı, bu yüzden bir noktada para kazanması gerekecek; bu nedenle tahminim, bir şekilde satıcı bağımlılığı yaratacak bir hepsi bir arada çalıştırıcı hâline getirmeye çalışıyor olabilirler
  Elbette yanılıyor olabilirim, ama bu tür bağımlılıkları core/standart kütüphaneye koymak gerçekten pek mantıklı değil
- Pek çok kişi Bun’ın yazarı Jared’a aynı şeyi söyledi, ama Jared’ın düşüncesi Bun’ın varsayılan bir projenin ihtiyaç duyduğu her şeye sahip olması gerektiği yönünde
  Core’a koyunca üçüncü taraf kütüphanelerden daha fazla optimize edebileceğini düşünüyor gibi
  Kişisel olarak bunun yanlış bir yaklaşım olduğunu ve Jared’ın fazla hırslı davrandığını düşünüyorum, ama sonuçta bu onun tutku projesi
- İsteğe bağlı kütüphanelerin daha iyi olduğuna tamamen katılıyorum
  Bun tarafının ifadesiyle “Bun, bulut öncelikli bir JavaScript runtime’ı olmayı hedefler. Yani bulutta prodüksiyon uygulamaları çalıştırmak için gereken tüm araçları ve hizmetleri destekler”; ama bu söz bana pek güven vermiyor
  Bu belirli tasarım tercihi Node’dan bile daha kötü görünüyor
- Bu, Bun’ın yönetilen sağlayıcı hizmeti için
  VC destekli yazılımlardaki sorun her zaman şu oldu: Bu entegrasyonlar kendilerine özgü bir şey sunmaya çalışıyor, başka bir deyişle bağımlılık yaratmaya çalışıyor
Şimdiye kadarki Bun kullanım deneyimim çok iyiydi
Yeni projelerde TypeScript/Jest/React/Webpack ayarlarken orada burada çıkan kırıcı değişiklikler yüzünden hep çekinirdim; Bun’da ise bunlar kendi içinde çözülüyor ve benim kullanımımda acısız şekilde çalışıyor
S3, SQL gibi üçüncü taraf kütüphane entegrasyonları için ne desem bilemiyorum, ama en azından en yaygın kullanılan ve en çok istenen şeylere odaklanıyor gibi
Node.js araç ekosistemine gereken normalliği getirdiği için hoşuma gidiyor
- Yukarıda bahsedilen frontend teknoloji stack’inde Bun’ın ne fark yarattığını merak ediyorum
- React/TypeScript projelerini Vite veya Next.js ile de gayet iyi kurabiliyordum
  Diğer araçların da bu süre içinde çok geliştiğini hafife alıyor gibisiniz
- Bun harika
  Benim için bir üretkenlik hilesi gibi
  ChatGPT Bun’ı pek bilmediği için biraz üretkenlik kaybı oluyor, ama yine de Bun’ı seviyorum
Güzel pek çok şey var, ama bazı varsayılan davranışların fazla sihirli şekilde gizli davranışlara dönüşmesinden endişeliyim
new Response(s3.file(...)) kullandığınızda Bun, S3 dosyasını sunucuya indirip kullanıcıya göndermek yerine kullanıcıyı S3 dosyasının önceden imzalanmış URL’sine yönlendiriyor
Varsayılan olarak oldukça şaşırtıcı bir tercih; S3 bucket’ını doğrudan açığa çıkarmak istemediğinizde bunu nasıl kapatacağınız da hiç açık değil
- Bun’ın açmaya çalıştığı alanı takdir ediyorum, ama yapımcıyı Twitter’da takip edince karar alma süreçlerinin kısa vadeli kazanımlara ve kolaylığa fazlasıyla yatkın olduğunu, o sihirli davranışların derin etkilerini ise hafife aldığını görüyorsunuz
  Başta bu projeden umutluydum, ama sosyal medyada açıkça görülen dağınık ve kişisel olarak çoğu zaman iyi bulmadığım tasarım kararlarına bakınca uzun vadeli yönüne güvenemiyorum
  v0.x olarak kalsaydı sorun olmazdı, ama 1.0 çıktıysa API yüzeyini genişletme eşiği çok daha yüksek olmalıydı
- Yanıta stream’i geçirmeniz yeterli
  Response(file.stream())
- Neden böyle yaptıklarını anlıyorum ama bu tasarımı sevmiyorum
  Kişisel olarak yan etkisi güçlü bir davranış gibi geliyor; okurken URL değil, dosya içeriğini döndürüyor gibi görünüyor
  Yine de bucket’ın açığa çıkmasında neyin rahatsız edici olduğunu da merak ediyorum
  Önceden imzalanmış URL olduğu için geniş erişim yetkisi de vermiyor
  Response((file(...).getPresignedURL())) gibi açık bir API daha iyi olurdu; ya da bu davranışı ortam değişkeni veya Bun ayarıyla açmaya yarayan bir seçenek olsaydı daha iyi olurdu
Piller dahil yaklaşımı büyük fark yaratır
Fetch API, Service Workers, Web Components, ES6+, WebRTC gibi web API’lerinin artık hem V8 hem de WebKit çalışma zamanlarında yerel hâle gelmesini sevmemin nedeni de bu
Ancak bunun bir ölçüsü olmalı
S3 fazla ileri gitmek olabilir ama SQL sürücüleri mantıklı
Yine de sorun, nereye kadar dahil edileceği
Veritabanı çok fazla; bunların yarısının sürücülerini mi eklemek gerekiyor?
Sadece o seviyede bile çok fazla ek kod olur ve çalıştırılabilir dosyayı yavaşlatabilir
Ayrıca Bun’a bu kadar hassas bir API koymak güvenlik açısından da gözden kaçan riskler yaratabilir
Bir betik ya da yol sorunu yüzünden eval çalıştığını ve Bun’ın tüm kaynak dosyalarını kişisel bir S3’e yüklediğini hayal edin; o anda iş biter
- “Ek kod artarsa çalıştırılabilir dosya yavaşlar” ifadesinin gerçekten böyle olup olmadığını merak ediyorum
  Kodun çalışma zamanında nasıl yüklendiğine bağlı olarak neredeyse ihmal edilebilir düzeyde olabileceğini düşünmüştüm
  Kod yükleme yalnızca import ifadesi görüldüğünde tetikleniyorsa pratikte hız ek yükü yok sayılmaz mı?
  Statik olarak linklenmiş olsa bile, sırf kodun var olması nedeniyle çalıştırılabilir dosyanın dikkate değer ölçüde neden yavaşlayacağını pek bilmiyorum
  Belleğe yüklenecek çalıştırılabilir dosyanın kelimenin tam anlamıyla daha büyük olması gibi bir durum var ama hissedilir bir yavaşlama olmayacak gibi
- Daha önce HN’de tarayıcıların SQLite’ı birinci sınıf desteklememesinin nedeni üzerine bir tartışma vardı; o argüman Bun için de geçerli olabilir
  Esas mesele, kütüphanenin bakım sorumluluğunun kimde olduğu ve SQLite değiştiğinde o kütüphanenin nasıl değiştirileceği
  SQLite’ta bir hata varsa Bun’da nasıl düzeltilecek?
  Hangi sürümlere düzeltme girecek?
  Çalışma zamanına yapılan bir yama, onun üzerinde çalışan kodun davranışını değiştirebilir; kullanıcılar eski davranışa göre geçici çözümler geliştirdiyse bu nasıl ele alınacak?
  Bunlar bir ölçüde çözülebilir sorunlar ama dezavantajları da var
  Bir noktadan sonra artık çalışma zamanı değil, platform hâline gelirsiniz; bununla birlikte başka sorumluluklar ve sorunlar gelir
- S3’ün dahil edilmesini savunanların dayanağının, S3 uyumlu API uygulayan çok sayıda nesne depolama servisi olması olduğunu düşünüyorum
  Gerçek bir web standardı değil ama pek çok kişinin fiilî standart gibi uyum sağladığı bir hedef
- “Ek kod artarsa çalıştırılabilir dosya yavaşlar” deniyor ama yazıda kelimenin tam anlamıyla benchmark var ve Bun’ın en hızlı Node.js çözümünden iki kat hızlı olduğu söyleniyor
Yakın zamanda bir müşterimiz Bun’ı prodüksiyonda kullandı
Hızı ve sadeliği nedeniyle Bun’ın geliştirici deneyiminin inanılmaz derecede iyi olduğunu duydum
Geliştirici deneyimi uzun vadede büyük rol oynar
Kod tabanı ya da süreçler berbat durumdaysa, FAANG düzeyinde ücret vermediğiniz sürece iyi insanları kaybedersiniz
Henüz Bun’ı denemedim ama özellik listesi o kadar uzun ki hepsinin sağlam ve hatasız olacağı konusunda şüpheliyim
Umarım yanılıyorumdur; ilerideki bir projede bir kez çalıştırmayı düşünüyorum
Proje yönetimi açısından, henüz Node.js ile %100 uyumlu bile değilken neden S3 desteğine zaman harcandığı konusunda biraz kafam karışık
Next.js çok büyük bir ekosistem; Next.js müşterilerini getirebilirlerse S3 desteğinden çok daha büyük büyüyebilirler
- %100 uyumluluk pazarlama açısından iyi bir zaferdir ama uzun kuyruğun uyumluluğu ortalama kullanıcı için büyük fark yaratmayabilir
  Günlük kullanımda tüm Node.js API yüzeyinin gerçekte ne kadarını kullanıyoruz?
  İçindeki garip uç durumlara gerçekte ne kadar bağımlıyız?
- “Proje yönetimi açısından” demek, projenin ne olduğunu bildiğini varsayar
  Üzerinde çalışan insanlar da robot değil
  Bazı işleri anlamak zaman alır ve bu sırada başka işler de yapılabilir
  Her işi tek bir kişi yapmıyor
  “Next.js müşterilerini getirirse daha çok büyür” deniyor ama neye doğru büyüme?
  Bu para kazandırmıyor
  Bu VC destekli bir proje ve hedef Bun’ı ücretsiz sunup dünyadaki tüm kullanıcıları toplamak değil
- Uzun özellik listesinin tamamının sağlam ve hatasız olup olmayacağından şüpheliyim; özellikle de Zig ile yazılmış olması kafama takılıyor
  Zig’in bellek güvenliği çok düşük
  Artık yaşamayan bir değişkene başvurursanız segmentasyon hatası yerine rastgele, alakasız bir belleğe erişiyor
  Debug ve güvenli modlarda da böyle olduğu söyleniyor[0]
  Değişken adını ölü olarak işaretleyen ve öldüyse erişimi engelleyen bir bellek yaşam süresi sistemini bunun üzerine koymak bu kadar mı zor?
  Sonuçta “tanımsız davranış kullanma”[1] noktasına geliyoruz
  Bu yüzden internete açık web sunucusu gibi yerlerde Zig ile yapılmış hiçbir şeyi bulundurmak istemem
  [0] : https://news.ycombinator.com/item?id=41720995
  [1] : https://github.com/ziglang/zig/issues/16467#issuecomment-164...
- Ne çok sağlam ne de hatasız
  Geçen yıl denedim, sürekli çöküyordu
- bun add komutunun package.json içindeki boşlukları ve girintilemeyi korumaması hatasının düzeltilmiş olması ve artık girintileme ne kadar tuhaf olursa olsun koruması epey komik
  Bunu kim istedi, neden bunun için kod yazmaya değer görüldü bilmiyorum
HTML içe aktarma harika ve etkileyici
Bun 1.2’de HTML içe aktarma desteğiyle tüm frontend araç zincirinin tek bir import ifadesiyle değiştirilebileceği söyleniyor
Başlamak için HTML içe aktarmayı Bun.serve içindeki static seçeneğine verebilirsiniz
```
import homepage from "./index.html";

Bun.serve({  
  static: {  
    "/": homepage,  
  },

  async fetch(req) {  
    // ... api requests  
  },  
});  
```
- Bunun örneğin Vite’ın yerini almayı nasıl sağladığını merak ediyorum
  Hot Module Replacement, CSS önişleme, Vue SFC derleyicisi gibi framework’e özgü eklentilerin yüklenmesi mümkün mü?
  Statik dosya sunmak pek yeni bir şey değil, sanırım bir şeyi kaçırıyorum
Node.js’e rakip bir alternatif kadar başarısız olmaya mahkûm başka proje yoktur diye düşünüyordum ama denemekle iyi etmişim
Metin dosyalarını ve SQLite DB güncellemelerini işleyen çok sayıda bağımsız çalıştırılabilir script yazmam gerekiyordu; TypeScript’i, bun:sqlite [1] ve bun $ Shell [2]’i herhangi bir yapılandırma dosyası ya da yerel npm bağımlılığı yönetimi olmadan doğrudan kullanabildim
Sonrasında yeni JS/TypeScript projelerinde de denedim; yerleşik bundler [3] ve test desteği [4] de işe yarıyor, bağımlılık kurulumu da anında bitiyor
Her şeyin hızlıca ve hemen çalışması gerçek bir yaşam kalitesi artışı; artık Bun, yeni JS projelerinde ilk tercihim oldu
[1] https://bun.sh/docs/runtime/shell
[2] https://bun.sh/docs/api/sqlite
[3] https://bun.sh/docs/bundler
[4] https://bun.sh/docs/cli/test
- Ben de aynı fikirdeyim
  “Bunların hepsi gelecek yıl npm’e de gelir, ne anlamı var ki” tarafındaydım
  Sonunda Bun’ı denedim ve gerçekten şaşırdım
  Geliştirici deneyimindeki küçük unsurlar birikince büyük fark yaratıyor
  Benim projelerimde Bun gerçekten yeni nesil gibi hissettiriyor
Kısa süre önce Bun’ı ilk kez kullandım ve deneyim harikaydı
Tüm projelerimde TypeScript kullanmak için Webpack ya da Vite yapılandırıyorum; bir kez ayarlanınca neredeyse kusursuz çalışıyorlar ama kurulumun kendisi zahmetli ve küçük script’ler için buna değmiyor
Buna karşılık Bun doğrudan çalıştı
CLI’da TS’yi “doğrudan” çalıştırmak için node-ts mi ne olan bir araçla 10-30 dakika uğraşıp “modül değil”, “import/require kullanılamaz”, “ESM/CJS” gibi berbat mesajlarla boğuştum; yaygın düzeltmeler olan package.json modül tipini değiştirme, tsconfig değiştirme, import/require kullanımını değiştirme yollarının hepsini denedim
Yaklaşık 200 satırlık bir script’i çalıştırmaya çalışırken son çare olarak Bun’a geçtim ve harika çalıştı
- Güncel Node.js de artık bu tür durumlarda “TS’yi olduğu gibi çalıştırmayı” destekliyor
  node --experimental-strip-types index.ts
  Güncel Node yoksa tsx paketi bende iyi çalıştı
  ts-nodedan daha iyiydi
  Ancak iki seçenek de tip bilgisini öylece atıyor; Bun da aynı şekilde
Gittiği yön hoşuma gidiyor
Özellikle S3 ve Postgres için native destek eklenmesi, “framework’ü kendin birleştir” şeklindeki mevcut duruma alternatif olabilecek bir yaklaşım olduğu için çok mantıklı
Rails ve Laravel gibi tüm web framework’lerinde bu standart; JS ekosistemi de bundan büyük fayda sağlayabilir
Bence sonraki adım, migration ve şema yönetimi ile factory kurulumunu iyi yapabilen daha iyi bir varsayılan test deneyimi

Bun 1.2 yayımlandı: Node.js uyumluluğu, S3 ve Postgres yerleşik

Node.js uyumluluğu güçlendirildi

Yerleşik S3 API’si Bun.s3

Yerleşik Postgres istemcisi Bun.sql

Paket yöneticisi değişiklikleri

Test runner iyileştirmeleri

Bundler ve build özellikleri

CSS bundling

Bun çalışma zamanı API eklemeleri

SQLite istemcisi iyileştirmeleri

JavaScript'ten C derleme ve çalıştırma

musl ve Alpine Linux desteği

JavaScript dil özellikleri

Web API eklemeleri

Davranış değişiklikleri ve geçişte dikkat edilmesi gerekenler

Performans iyileştirmeleri

Kurulum ve yükseltme

İlgili okumalar

1 yorum

Hacker News görüşleri

Yerleşik S3 API’si `Bun.s3`

Yerleşik Postgres istemcisi `Bun.sql`