Nub - Toolkit all-in-one mirip Bun untuk Node.js

• Toolkit all-in-one yang melengkapi tanpa menggantikan Node.js, ditulis dalam Rust dan memberikan pengalaman pengembangan mirip Bun di atas node standar
• Menyatukan eksekusi file·skrip, instalasi dependensi, dan pengelolaan versi Node dalam satu alat, tanpa runtime baru, API khusus vendor, atau lock-in
• File runner nub <file> — menjalankan .ts, .tsx, dan lainnya tanpa tahap build, kompatibel node flag-for-flag dan var-for-var, startup 2,9× lebih cepat dibanding tsx
  • Dukungan TypeScript penuh (enum, namespace), JSX/TSX, Decorators, pemuatan otomatis .env*, serta loader bawaan untuk .yaml, .toml, .json5, dan lainnya
  • Mendeteksi dan memasang otomatis versi Node yang diharapkan proyek (mengacu pada .node-version, .nvmrc, package.json#engines, dll.)
• Script runner nub run — drop-in pengganti npm/pnpm run, biner Rust tanpa startup JS internal dengan dispatch sekitar 24× lebih cepat dibanding pnpm run (14.7ms vs 442.7ms)
  • Dukungan penuh untuk hook pre/post, pnpm workspace --filter·--parallel, dan lainnya
• Package runner nubx — drop-in pengganti npx·pnpm dlx, menghilangkan penalti double-Node-spawn sehingga eksekusi sekitar 19× lebih cepat dibanding npx (11ms vs 226ms)
• Package manager nub install — berbasis engine Aube, kompatibel dengan flag pnpm, 2,5× lebih cepat dari pnpm dan 3,7× lebih cepat dari npm
  • Kebijakan keamanan bawaan secara default — memblokir postinstall, memeriksa paket berbahaya lewat osv.dev, menolak provenance downgrade, dan minimumReleaseAge 24 jam
  • Berjalan dalam compat-mode yang otomatis mendeteksi lockfile dan konfigurasi npm/pnpm/Yarn/Bun
• Node version manager nub node — menyediakan perintah pengelolaan manual seperti install·ls·uninstall·pin versi
• Package meta-manager nub pm — menjalankan peran Corepack dalam Rust native, mendaftarkan shim global npm·yarn·pnpm
• Lisensi MIT

[GN⁺]

Komentar Hacker News

• Idenya sangat bagus dan masuk akal. Bun memang menyediakan lebih banyak hal seperti driver DB, tetapi jelas bahwa pengalaman pengembang juga merupakan bagian besar dari daya tariknya
  Sebagai catatan, penulis utama Nub adalah Colin McDonnell, pembuat Zod, dan dulu pernah bekerja di Bun

  • Betul. Nub sengaja tidak menambahkan API khusus Nub sama sekali: tidak ada objek global Nub, tidak ada modul bawaan berawalan nub:, tidak ada file konfigurasi/file lock bernama Nub, tidak ada field nub di package.json, dan tidak ada variabel lingkungan NUB_
    Menurut saya, sebagian besar hal yang ditambahkan Bun lebih baik dijadikan dependensi yang semestinya

• Agak mengejutkan mereka memakai hook --require alih-alih --import. Mungkin ada banyak hal yang sudah berubah sejak saya meneliti cara membuat fitur serupa, tetapi saya curiga ada sisi rumit dalam dukungan ESM Nub
  Saat itu --import di Node masih sangat awal, dan ada beberapa kasus pengecualian yang ingin ditangani dengan pendekatan ESM-to-CJS yang umum. Kebanyakan mungkin sangat niche, tetapi top-level await tampaknya akan memengaruhi sebagian pengguna yang cukup berarti

  • Ini dipakai untuk registrasi preload murni demi performa. Dalam kasus ini dan banyak kasus lain, CommonJS masih lebih cepat daripada ESM. --require menambah overhead sekitar 0,5 ms, sedangkan --import sekitar 4,6 ms di M1 Macbook Pro
    Terkait ini, Node.js baru-baru ini pada 2025 memperkenalkan module.registerHooks(), versi sinkron dari API registrasi hook resolver, untuk meningkatkan performa dibanding API module.register() lama yang asinkron. Ini menghilangkan hambatan besar bagi Nub. Sebagai tambahan bagi yang tertarik, API asinkron menambahkan overhead registrasi tetap 19 ms dan tambahan overhead sekitar 130us untuk setiap import
    Flag apa yang dipakai Nub di sini sama sekali tidak memengaruhi kode pengguna, dan top-level await didukung di tempat yang memang sudah didukung oleh Node.js sendiri

• Kami baru saja me-merge PR untuk memigrasikan seluruh monorepo kami ke nub
  Nol masalah, dan cepatnya tidak masuk akal

  • Maksudnya, dalam waktu kurang dari satu jam setelah ini diposting, kalian sudah me-merge PR yang memigrasikan monorepo bersama ke ini?

• Bukannya Node sudah bisa menjalankan TypeScript sejak beberapa versi lalu? Kenapa masih perlu transformer?

  • Dukungan TypeScript bawaan Node hanya melakukan type stripping. Itu bisa menangani sangat banyak bagian dari sintaks TypeScript, tetapi tidak semuanya. Ia juga tidak benar-benar memeriksa tipe, hanya menghapusnya agar bisa dijalankan. Hal-hal seperti tsconfig juga hilang
    Ini tampaknya mendukung baik pendekatan penghapusan bawaan maupun pemrosesan TypeScript yang sesungguhnya
  • Tim Node.js menghapus --experimental-transform-types di Node.js v26. Ini membuat dukungan TypeScript penuh secara native jadi mustahil
    https://github.com/nodejs/typescript/issues/51#issuecomment-...
  • Tertulis bahwa ini akan menyuntikkan polyfill bila diperlukan untuk API seperti Worker dan Temporal

• Di README tertulis dukungan WebSocket native mulai Node 22, tetapi Node tidak punya library WebSocket native. Tautan standar WebSocket mengarah ke MDN, dan di sana hanya dijelaskan antarmuka pengguna WHATWG, bukan protokol atau cara kerja WebSocket
  Rasanya ada yang hilang, atau seperti memakai library non-native sebagai pelengkap

  • Sejak 22, Node mendukung klien WebSocket bawaan, tetapi belum mendukung server

• Patut dihargai bahwa mereka menerima teknologi yang sudah ada dan tidak membuat ulang versi yang lebih buruk. Saya penasaran, kalau semua upaya yang dipakai untuk membuat alternatif justru diarahkan ke Node, dengan kepemimpinan yang tepat, kita bisa sudah sampai sejauh apa sekarang

  • Anda mungkin ingat fork io.js dari Node.js pada 2014. Saat Node mandek, banyak orang mem-fork ke io.js, yang pada akhirnya digabungkan kembali ke Node dan mengembalikan Node ke jalurnya. Kalau ditarik lebih jauh lagi, CoffeeScript, yang dulu merupakan “fork” dari JS, juga punya ide-ide terbaiknya yang kemudian diserap ke ES5
    Tim kecil yang lincah bisa membuktikan ide bagus karena kegagalan bukan risiko yang fatal. Singkatnya, fork adalah bagian dari ekosistem yang sehat
  • Pada dasarnya ada banyak hal yang memang tidak bisa diperbaiki dengan pendekatan seperti ini
    Contoh sederhana: Node adalah satu-satunya perangkat lunak open source serius yang saya tahu tidak punya cara untuk mendokumentasikan konfigurasi di dalam file konfigurasi. Ini konyol. Pihak Node mengadopsi JSON tanpa banyak pikir, lalu setelah itu menolak mempertimbangkan alternatif apa pun, termasuk “JSON dengan komentar”
    Jika sebuah organisasi terjebak pada keputusan buruk, satu-satunya cara memperbaikinya adalah mulai dari awal. Selama semua orang terus menumpuk di atas Node, seluruh ekosistem JS tidak akan bisa meninggalkan dokumentasi di konfigurasi
    Ada beberapa masalah seperti ini di ekosistem Node, dan absurditas total bahwa konfigurasi tidak bisa didokumentasikan hanyalah titik keluhan pribadi saya

• Saya penggemar Nub dan maskotnya, nubnub. Serius, ini proyek yang hebat, cukup menarik, dan saya sudah terus memakainya sejak minggu lalu, atau setidaknya sejak dirilis ke publik

• Cerdas. Kalau sudah ditulis dalam Rust, setidaknya tidak akan ada migrasi ke Rust lewat vibe coding lalu kehilangan semua pelanggan ;)

  • Setelah diakuisisi OpenAI, mungkin proyek berikutnya diganti ke Zig
  • Proyek ini sendiri sudah punya porsi vibe coding yang besar. Kontributor kedua terbesar di repositorinya adalah Claude
  • Mungkin akan lebih pas kalau dibilang, “kalau sudah di-vibe-code dalam Rust”. Secara umum Nub memang cukup memberi kesan seperti itu. Tidak masalah sih, hanya terasa lucu kalau dibandingkan dengan Bun
    Tambahan lagi, histeria anti-AI terhadap Bun sangat menyedihkan, dan kadang bahkan terasa seperti kampanye yang terorganisasi
  • Malah lebih membantu lagi kalau sejak awal memang sudah di-vibe-code dan juga tidak punya pelanggan
  • Betul. Saya tidak yakin apa nilai tambah dari bagian “ditulis dalam Rust” di sini. Rasanya fungsi yang sama bisa dicapai dengan beberapa shell script dan package.json