Bun v1.0.0 - Toolkit all-in-one cepat untuk menjalankan, membangun, menguji, dan men-debug JavaScript dan TypeScript

• Bun 1.0 menangani eksekusi, build, pengujian, dan debugging JavaScript serta TypeScript dalam satu alat, dan kini sudah stabil serta siap untuk produksi
• Dengan tujuan menjadi pengganti Node.js, Bun mendukung API Node dan resolusi modul seperti fs, path, net, __dirname, process, resolusi node_modules, dan lainnya; Express, Koa, Hono, serta aplikasi berbasis Next.js, Remix, Nuxt, Astro, SvelteKit, Nest, SolidStart, dan Vite dapat berjalan di Bun
• Build native untuk Windows kini tersedia untuk pertama kalinya, tetapi sangat eksperimental; saat ini hanya mendukung runtime JavaScript, sementara package manager, test runner, dan bundler dinonaktifkan
• Perubahan sejak Bun 0.8 mencakup penambahan dukungan untuk Next.js, Astro, dan Nest.js, serta penghapusan perintah bun dev yang sebelumnya sudah tidak direkomendasikan; kini perintah tersebut menjalankan skrip "dev" di package.json
• API Node.js yang baru didukung mencakup child_process.fork() dan IPC, fs.cp(), fs.cpSync(), fs.watchFile(), fs.unwatchFile(), serta Unix socket pada node:http
• Runtime-nya memiliki transpiler JavaScript bawaan, sehingga file .js, .ts, .cjs, .mjs, .jsx, .tsx dapat dijalankan tanpa dependensi tambahan
• Mendukung ESM dan CommonJS secara bersamaan, sehingga import dan require() bisa digunakan dalam file yang sama tanpa bergantung pada ekstensi file atau pengaturan "type": "module" di package.json
• API standar Web seperti fetch, Request, Response, WebSocket, dan ReadableStream sudah terintegrasi, sehingga bisa digunakan tanpa paket seperti node-fetch dan ws
• Hot reload dapat digunakan melalui opsi --hot, dan Bun.serve() juga menjadi target hot reload
• API Bun menyediakan Bun.file(), Bun.write(), Bun.serve(), bun:sqlite, dan Bun.password untuk menangani input/output file, server HTTP/WebSocket, SQLite, serta hash dan verifikasi kata sandi bcrypt·argon2
• Package manager menyediakan bun install, bun add, bun remove, dan bun update, dengan cara yang kompatibel dengan npm: membaca package.json dan menulis ke node_modules
• Test runner bun:test menyediakan API yang kompatibel dengan Jest, dan secara internal memetakan ulang import @jest/globals dan vitest ke bun:test
• Bundler mendukung bundling dan minify JavaScript serta TypeScript, menyediakan API plugin yang kompatibel dengan esbuild, dan menghadirkan macro JavaScript yang menjalankan fungsi JavaScript saat proses bundling untuk meng-inline nilai

[GN⁺]

Pendapat Hacker News

• Saya ikut mengembangkan Bun. Kalau ada pertanyaan, saya bisa menjawabnya
  Akan bagus kalau moderator mengganti tautannya ke tulisan blog, karena penjelasannya lebih baik daripada halaman rilis GitHub
  Tulisan blog: https://bun.sh/blog/bun-v1.0

  • Sudah diganti dari https://github.com/oven-sh/bun/releases/tag/bun-v1.0.0

• Hal yang paling mengesankan adalah bisa memakai import dan require() dalam file yang sama, tanpa perlu memikirkan .js/.cjs/.mjs atau "type": "module"
  Tanpa ini, ekosistem Node.js terasa hampir sepenuhnya rusak, dan Bun tampaknya bisa menyelamatkannya. Menurut saya hal paling hebat dari Bun bukan performanya, melainkan pilihan-pilihan praktis dan ramah developer yang terus diambil Jarred

  • Masalah ini sudah lama ada, dan saya ragu Bun benar-benar lebih “menyelesaikannya” dibanding tool lain
    Mereka hanya memilih kompromi yang berbeda, dan akibatnya kemungkinan ada kumpulan package lain yang tidak berjalan. Saya penasaran apakah ada dasar untuk menganggap Bun telah memecahkan rahasia yang tidak bisa dipecahkan tool lain
  • Saat Node mengusulkan pemisahan sintaks, saya mendorong agar pendekatan seperti ini didukung, dan senang sekali Bun mengadopsinya
    Menurut saya, ini adalah cara yang benar. Ekosistem Node yang terpecah telah sangat merugikan bahasa dan runtime secara keseluruhan
  • Setiap beberapa tahun saya harus banyak memakai JavaScript, dan ketika baru-baru ini mendalaminya lagi, saya menghabiskan berjam-jam bergelut dengan import vs require
    Kalau tidak memakai aplikasi React atau solusi siap pakai, ekosistem JS modern benar-benar menyakitkan, terutama bagi orang yang membuat library kecil. Saya bahkan tidak bisa membayangkan betapa sulit dan bikin frustrasinya ini bagi pemula
    Fakta bahwa Bun menyelesaikan masalah itu saja sudah cukup menjadi alasan untuk mencobanya. Saya tidak menyangka akan merasa antusias terhadap satu lagi runtime atau build tool JS, dan berkat tim Bun saya berharap hari-hari saya bisa sedikit lebih waras
  • Hampir sejak 1 tahun lalu saya pada dasarnya membuat proyek berbasis modul. Setelah strategi resolusi bundler muncul di TypeScript 5.0, 6 bulan terakhir umumnya cukup baik
    Ada masalah yang sangat jarang, tetapi sampai proyek-proyek memperbaikinya, saya mengakalinya dengan pnpm patch dan perubahan meta. Tahun 2023 bisa dibilang tahun modul, dan kondisi airnya baik-baik saja
  • Setuju. Saya seharusnya sudah menjadi ahli JavaScript sekarang, tetapi tidak ada yang membuat saya merasa sebodoh saat harus menavigasi type: module dan .js/.cjs/.mjs/.ts
    Di aplikasi produksi tentu saja harus jelas apa yang dipakai, tetapi untuk prototyping, perilaku Bun yang permisif membuat kita bisa menulis kode dulu dan memikirkan sisanya nanti

• Saya bertanya-tanya apakah untuk rilis 1.0 yang belum mengimplementasikan seluruh node: tidak ada frasa yang lebih baik daripada pengganti drop-in
  Saya cukup kecewa karena dua proyek pertama yang saya coba ternyata bukan pengganti drop-in, dan sekarang saya jadi meragukan semua komunikasi Bun
  Sebagai konteks, kedua proyek itu memakai osc yang membutuhkan dgram. Saya menemukan tiket pelacakan permintaan fitur dari 9 bulan lalu, tetapi tidak ada rencana implementasi, dan ketika mencari dgram di halaman pengumuman ini tidak ada hasil apa pun
  Saran cepat: sebaiknya modul yang belum didukung Bun 1.0 disebutkan secara eksplisit dan dimasukkan ke bagian kompatibilitas Node.js
  Sunting: Saya menemukan dokumentasi dukungan Node — https://bun.sh/docs/runtime/nodejs-apis . Akan bagus kalau ditautkan di catatan rilis
  Sekilas, tampaknya ada sekitar 17 modul yang diimplementasikan, 17 diimplementasikan sebagian, dan 7 belum diimplementasikan

  • Versi sebenarnya tampak lebih dekat ke 1.0.0-beta daripada 1.0.0
    Saya baru saja menginstal v1.0.0 dan menjalankan bun repl, tetapi gagal dengan exit code 1; ternyata REPL mencoba memakai port 3000, yang di lingkungan saya sudah digunakan. Melihat bug yang dilaporkan di GitHub, sepertinya ada cukup banyak masalah kecil seperti ini, jadi rasanya semua klaim perlu disikapi dengan cukup skeptis
    Meski begitu, saya sangat terkesan dengan kecepatan dan hasilnya. Saya tidak menyangka proyek ini bisa sampai sejauh ini secepat ini, dan mengira akan butuh jauh lebih lama. Sebagai perbandingan, Deno mulai jauh lebih awal tetapi sekarang terasa tertinggal cukup jauh, jadi saya berniat mencoba Bun untuk proyek pribadi
  • Yang penting bukan jumlahnya, melainkan modul yang mana
    Secara anekdotal, kami sedang menguji Bun pada aplikasi besar dengan jutaan pelanggan eksisting, dan sejauh ini satu-satunya masalah bukan pada Bun sendiri, melainkan patch-package yang belum mendukung lockfile bun.lockb
    Bun tidak diragukan lagi jauh lebih cepat daripada Yarn. Saya mengatakan ini sebagai orang yang sangat menyukai Yarn
  • Di bagian kompatibilitas Node.js sudah tertulis seperti ini
    “Note — For a detailed breakdown of Node.js compatibility, check out: bun.sh/nodejs.”
    Daftar detailnya menyebutkan modul yang tidak didukung
  • Saya setuju dengan pendapat ini. Saya benar-benar menantikannya dan mencoba memakainya, tetapi sebagian besar proyek kami tidak bisa dijalankan
    AWS SDK v3 tidak bisa dipakai karena terjadi error saat parsing respons, dan karena node:crypto belum sepenuhnya diimplementasikan, kami tidak bisa memakai hal-hal yang bergantung pada octokit atau jsonwebtoken. jest.resetAllMocks() tidak ada sehingga test tidak bisa dijalankan, dan di proyek lain bun test bahkan tidak berjalan sama sekali karena mengatakan panggilan shared library salah
    Jadi alur kerja lokalnya adalah “coba jalankan dengan Bun, kalau gagal jalankan lagi dengan Node”. Setidaknya mungkin bisa dipakai sebagai pengganti npm, tetapi saya masih sulit membayangkan memakainya untuk menjalankan layanan. Saat berhasil, hasilnya benar-benar mengesankan sehingga saya menantikan masa depannya, tetapi kalau poin jualnya adalah kompatibilitas Node, menurut saya sulit menyebutnya 1.0

• Saya penasaran apakah pernah terpikir untuk memindahkan chat komunitas ke platform selain Discord
  Discord sudah beberapa kali dibahas di HN karena masalah aksesibilitas, privasi, dan ketergantungan pada platform proprietari, dan tampaknya juga kurang sejalan dengan semangat open source. [1] juga layak dijadikan referensi
  [1] https://drewdevault.com/2021/12/28/Dont-use-Discord-for-FOSS...

  • Meski penting untuk tidak memakai Discord, sepertinya kecil kemungkinan itu akan berubah
    Di komentar pengumuman Bun 0.6 pun, pertanyaan serupa mendapat downvote sampai hampir ditandai flag: https://news.ycombinator.com/item?id=35970869
    Di komentar pengumuman Bun 0.8, pertanyaan yang sama juga hampir tidak mendapat perhatian, dan responsnya kira-kira, “proyek lain juga semua memakainya…”: https://news.ycombinator.com/item?id=37244294
  • Aksesibilitas Discord sudah meningkat cukup banyak. Pengguna screen reader yang ada di bagian sumber tulisan tersebut juga belakangan setuju bahwa aksesibilitas Discord sudah membaik dan makin banyak penyandang tunanetra yang menggunakannya
    Sejujurnya, Discord adalah tempat yang baik bagi proyek perangkat lunak bebas dan open source untuk menaruh komunikasi komunitas. Argumen dalam tulisan itu bahwa “memilih Discord berarti melegitimasi platform tersebut dan mengambil nilai dari platform FOSS” terasa cukup rapuh. Discord memang platform yang sah, gratis, punya banyak fitur menarik, dan aksesibilitasnya juga baik. Yang terpenting, memilih Discord tidak membuat nilai platform komunikasi FOSS hilang
    Saran untuk “pakai IRC” juga tidak tepat. IRC sangat sulit diakses bagi banyak orang yang tidak terbiasa dengan komputer dan perangkat lunak
  • Apakah ada alternatif FOSS untuk Discord yang tidak memerlukan biaya?
  • Bisakah answeroverflow.com menjadi solusi sementara?

• Bun berbasis pendanaan ventura, jadi saya penasaran dengan rencana monetisasinya
  Saat melihat teknologi baru, saya mempertimbangkan “seberapa besar kemungkinan teknologi ini masih aktif dikembangkan dalam N tahun ke depan”. Bun harus menghasilkan uang dengan suatu cara, kalau tidak pendanaannya akan terhenti
  Lisensi Bun yang MIT itu bagus, dan memberi harapan bahwa proyeknya tidak harus mati meski perusahaannya bangkrut. Saya berharap perusahaannya sukses, tetapi jika mengadopsi Bun, saya penasaran upsell seperti apa yang mungkin muncul nanti

  • Rencana bisnisnya dijelaskan di https://oven.sh/
    Oven akan menyediakan hosting serverless dan continuous integration yang sangat cepat untuk aplikasi JavaScript backend dan frontend, dan akan ditenagai oleh Bun
    Rencananya akan mendukung framework frontend seperti Next.js, Vite, SvelteKit, SolidStart, serta framework backend seperti Express, Fastify, dan NestJS
    Rencananya mereka akan mengoperasikan server sendiri di edge data center di seluruh dunia, dan Oven ingin mengintegrasikan seluruh stack JavaScript secara end-to-end hingga ke hardware untuk membuka kemungkinan baru
  • Karena ini bundler, sepertinya mereka akan menghasilkan uang dari hosting aplikasi JS dalam bentuk seperti bun deploy
    Ini strategi umum: terlebih dahulu mendapatkan adopsi developer dalam skala besar, lalu mengarahkan mereka secara halus ke hosting aplikasi milik sendiri
  • Dulu ada dev server HMR keren bernama Pundle. Cukup cepat untuk terasa instan, tetapi juga proyek yang dikelola satu orang dari negara miskin
    Saya terlalu kerepotan mencoba mengikuti side project satu orang, jadi memindahkan semuanya ke Rollup dan tidak pernah menoleh ke belakang
    Kekhawatiran pada proyek yang didanai ventura dan side project acak jelas berbeda, tetapi risiko akhirnya sama-sama “bagaimana kalau pembuatnya tidak bisa mendukung saya?”
  • Sepertinya akan mengarah seperti NextJS/Vercel atau Deno/Deploy, dan menurut saya perubahan lisensi juga tidak bisa dikesampingkan
    Caranya adalah mempromosikan semuanya sebagai “open source” untuk mendapatkan laporan bug gratis, kontribusi, pemasaran, dan adopsi, lalu mendorongnya ke produk komersial

• Gagasan bahwa Bun bisa menggantikan kekacauan berlapis dari tool berbasis Node sangat menarik
  Karena ini bisa mengurangi node, ts-node, nodemon, tsc, jest, ts-jest, webpack, Babel, 2 spesifikasi modul yang tidak saling cocok, kekacauan UMD, 3 package manager, dan ledakan file konfigurasi yang diakibatkannya
  Ekosistem tooling di sekitar JavaScript jelas adalah sumber sakit kepala terbesar, dan membuat ES6 + TypeScript—yang pada dasarnya bahasa yang cukup mumpuni dan nyaman—menjadi pekerjaan remeh yang merepotkan. Saya berharap Bun berhasil
  Rasanya mungkin akan mirip seperti beralih dari CMake ke Cargo

• Tulisan blognya menunjukkan proposisi nilai software all-in-one yang lebih sederhana dengan sangat meyakinkan
  Belakangan ini saya lebih tertarik pada software “batteries included” daripada “bawa semuanya sendiri”, jadi saya menantikan untuk mencoba Bun
  Rasanya seperti versi runtime dari tool Rome yang dulu mencoba menggantikan banyak software dengan satu yang lebih cepat. Rome gagal dan beralih menjadi OSS oleh tim baru. Saya berharap Bun lebih berhasil, tetapi ini jelas masalah yang sulit dipecahkan

  • Saya setuju dengan pendekatan “batteries included”. Kalau sejak awal ekosistem Node.js lebih selaras, pendekatan seperti ini tidak akan diperlukan
    Jika memiliki dan mengendalikan hardware serta sistem operasi sendiri seperti Apple, kita bisa mengoptimalkan sistem secara mendalam, dan juga memberi rasa aman bahwa semua perangkat bekerja mulus. Kumpulan tool all-in-one mengurangi beban untuk berlari-lari mencari solusi sempurna, dan membuat kita memakai solusi yang sudah ada di depan mata

• Kepada orang yang sudah mencoba Bun dan Deno, saya ingin mendengar mana yang sebenarnya lebih meyakinkan sebagai penerus Node
  Situs web Bun mengklaim performanya jauh lebih baik daripada Deno, dan saya penasaran apakah memang begitu dalam praktiknya. Kalau ya, saya juga ingin tahu alasannya. Deno juga tampaknya punya tujuan yang mirip
  Saya juga penasaran apakah ada perbedaan filosofis yang besar di antara kedua proyek ini. Misalnya, apakah Bun mencoba mengimplementasikan ulang segala macam hal, sementara Deno menginginkan cara baru setelah Node. Ada yang sudah cukup memakai keduanya?

  • Keduanya tidak terlalu membuat saya tertarik, tapi sejak awal saya penasaran kenapa kita butuh penerus Node
    Bun dan Deno sama-sama tool berbasis pendanaan ventura, jadi ada keraguan mendasar soal monetisasi dan keberlanjutannya
    Nilai jual utama Bun tampaknya adalah performa, tetapi saya jarang mengalami masalah performa besar di Node. Memang tidak super cepat, tetapi jauh lebih mungkin terbentur batasan I/O daripada kecepatan Node
    Nilai jual utama Deno adalah “Node yang dibuat dengan benar” dalam banyak hal, seperti packaging yang lebih baik dan penggunaan penuh ES6, dan klaim itu menarik bagi saya. Namun sepertinya mereka menyerah pada upaya membangun ekosistem baru dan beralih menambahkan kompatibilitas Node
    Pada saat yang sama, peningkatan terbaru di Node sendiri seperti test runner bawaan dan dukungan .env bawaan cukup menggembirakan. Jadi sulit menemukan alasan kuat untuk memakai Bun atau Deno, dan kalaupun pindah, saya butuh jalur konkret untuk kembali ke Node jika tool generasi baru itu tidak berkelanjutan
  • Tool-tool ini masih terlalu muda untuk bisa dibilang ada orang yang benar-benar sudah memakainya sangat lama
    Bun menggabungkan semuanya dan membuatnya sangat cepat, sambil berusaha mempertahankan kompatibilitas dengan Node sejauh mungkin. Mereka tidak meninggalkan ekosistem yang sudah ada
    Deno mengambil pandangan yang terlalu konfrontatif terhadap ekosistem Node, dan sekarang sedang menambahkan kembali dukungan
    Dari sudut pandang penerus, menurut saya Bun adalah satu-satunya pilihan. Karena mereka berusaha berinovasi dengan fitur baru sambil mempertahankan kompatibilitas Node
  • Saya bukan pengguna mahir dan terutama hanya mencoba-coba Deno
    Deno lebih terlihat seperti runtime Node alternatif dengan keamanan sebagai prinsip utama, serta menyertakan tool seperti dukungan bawaan untuk TypeScript dan JSX, juga linter. Ia juga berbasis V8. Terlihat mendekati bentuk yang belakangan menurut Ryan Dahl seharusnya menjadi Node
    Bun secara teknis berbasis WebKit, tetapi saya tidak tahu persis kenapa, dan tampaknya bukan hanya runtime melainkan tool all-in-one yang lebih baik. Ia juga menyediakan kompatibilitas bawaan dengan framework yang sudah ada. Sampai belum lama ini Deno tidak kompatibel dengan npm, dan saya juga penasaran apakah memang itu niat awalnya atau perubahan arah yang sedang berlangsung
  • Kami adalah tim full-stack TypeScript, mengelola sekitar 50 library internal dan sekitar 500 ribu baris TypeScript
    Bulan lalu kami menguji Deno dan Bun sebagai runtime alternatif. Ringkasnya, pada codebase yang cukup kompleks, Bun hampir selalu berjalan dan Deno hampir selalu tidak
    Sekarang kami menjalankan semua test di Node.js dan Bun, dan sudah menyerah mencoba menerapkan Deno
  • Kalau ingatan saya benar, Bun tidak mendukung Windows, tidak seperti Node/Deno
    Edit: sepertinya ini sedang berubah. Terima kasih atas koreksinya

• Awalnya rilis direncanakan kemarin, tetapi ada kegagalan test streaming body fetch() yang perlu diperbaiki
  Artikel blog seharusnya belum dipublikasikan sampai Bun 1.0 naik ke GitHub, tetapi tautannya bisa diakses publik dan ada bug yang membuat draft tidak tersembunyi dari RSS feed
  Bug sebenarnya bukan pada streaming body fetch(), melainkan pada binding JavaScriptCore yang mengambil properti dari objek yang propertinya mungkin belum didefinisikan. Sebagian kode hanya memeriksa apakah nilainya JSCell, tanpa memastikan apakah nilainya objek; JSCell biasanya objek, tetapi hal seperti symbol atau BigInt bukan JSObject
  Thread kemarin: https://news.ycombinator.com/item?id=37424724

  • Akan bagus kalau bagian instalasi di dokumentasi Linux diperbarui karena DEB/RPM belum dicantumkan
    Sebagai petunjuk tambahan, untuk instalasi dengan cara “mengunduh dari internet, bukan dari repositori distro”, bisa disediakan contoh playbook/task set Ansible dengan checksum yang sesuai seperti SHA-256. Puppet juga bisa, meski akan sedikit lebih rumit
    Ini bisa sedikit meringankan pekerjaan administrator sistem, dan kalau ingin diberi nama, bisa disebut SAX, yaitu pengalaman administrator sistem

• Jika Bun dapat menjalankan dan mem-bundle aplikasi TypeScript React secara bawaan, saya penasaran apa keuntungan memakai Vite.js di atasnya
  Panduan di situs resminya menunjukkan cara memakai Bun + Vite.js saat membuat aplikasi TypeScript React, jadi ini membingungkan. [1]
  Ada juga isu terkait di GitHub. [2]
  Apakah Vite.js menangani skenario yang lebih kompleks atau use case lanjutan yang tidak bisa ditangani Bun? Penggunaan Vite.js saya sebatas memulai dan mem-build dengan setup TS+React dasar, jadi mungkin ada sesuatu yang saya lewatkan
  [1] https://bun.sh/guides/ecosystem/vite
  [2] https://github.com/oven-sh/bun/issues/250

  • Vite masih memanfaatkan Node, esbuild, swc, tsc, dan lainnya untuk bagian-bagian yang tidak menjadi tanggung jawab langsungnya
    Saya belum punya pengalaman memakai Bun, tetapi pemahaman saya: untuk menjalankan server pengembangan lokal, Bun bisa dipakai alih-alih Node; untuk bundling, Bun bisa dipakai alih-alih esbuild atau tsc, Rollup, atau kombinasinya; dan untuk transformasi, Bun bisa dimanfaatkan alih-alih Babel dan TypeScript
    Yang disediakan Vite adalah konfigurasi yang memudahkan penyiapan pengembangan aplikasi frontend dan memberikan developer experience yang baik saat bekerja secara lokal
  • Saya melihat Vite dipakai bersama Bun hanya untuk keperluan HMR
    Saat ini masih ada kompleksitas konfigurasi, jadi menurut saya menggabungkan keduanya belum terlalu ideal
  • Meminta orang menerima seluruh ekosistem sekaligus itu beban besar
    Kompatibilitas dengan ekosistem yang sudah ada adalah tujuan inti Bun, jadi maksudnya agar orang bisa langsung mulai memakainya di codebase yang sudah ada dan secara bertahap mengadopsinya di lebih banyak bagian
  • Sepertinya bisa memanfaatkan ekosistem plugin Vite. Misalnya PostCSS, Tailwind, Terser
    Dan karena sebagian besar meta-framework baru seperti Nuxt, SvelteKit, Astro, SolidStart, dan Qwik berjalan di atas Vite, ini bisa membuka jalur adopsi Bun
  • Ini mirip dengan bertanya mengapa Vite diperlukan kalau sudah ada tsc
    Menurut saya Bun bukan benar-benar “menjalankan aplikasi TypeScript React”, melainkan lebih menyediakan transformasi JSX/TSX secara bawaan