Nub - Node.js के लिए Bun-जैसा ऑल-इन-वन टूलकिट

• Node.js को बदले बिना उसे बेहतर बनाने वाला ऑल-इन-वन टूलकिट, जो Rust में लिखा गया है और मानक node के ऊपर Bun-जैसा डेवलपमेंट अनुभव देता है
• फ़ाइल/स्क्रिप्ट चलाना, dependency install करना, और Node version management को एक ही टूल में एकीकृत करता है; कोई नया runtime, vendor-locked API, या lock-in नहीं
• File runner nub <file> — .ts, .tsx आदि को build step के बिना चलाता है, node के साथ flag-for-flag और var-for-var compatible, tsx की तुलना में startup 2.9× तेज़
  • पूरा TypeScript support (enum, namespace), JSX/TSX, Decorators, .env* auto-loading, .yaml, .toml, .json5 आदि के लिए built-in loader
  • प्रोजेक्ट को जिस Node version की ज़रूरत है उसका auto-detect और install (.node-version, .nvmrc, package.json#engines आदि को देखकर)
• Script runner nub run — npm/pnpm run का drop-in, JS startup के बिना native Rust binary के रूप में pnpm run की तुलना में लगभग 24× तेज़ dispatch (14.7ms vs 442.7ms)
  • pre/post hook, pnpm workspace --filter, --parallel आदि का पूरा support
• Package runner nubx — npx और pnpm dlx का drop-in, double-Node-spawn penalty हटाकर npx की तुलना में लगभग 19× तेज़ execution (11ms vs 226ms)
• Package manager nub install — Aube engine आधारित, pnpm के साथ flag compatible, pnpm से 2.5× और npm से 3.7× तेज़
  • डिफ़ॉल्ट security policy built-in — postinstall block, osv.dev malicious package scan, provenance downgrade से इनकार, 24 घंटे का minimumReleaseAge
  • npm/pnpm/Yarn/Bun lockfile और settings को auto-detect करने वाले compat-mode में काम करता है
• Node version manager nub node — version install, ls, uninstall, pin आदि के लिए manual management commands देता है
• Package meta-manager nub pm — Corepack जैसी भूमिका native Rust में निभाता है, npm, yarn, pnpm global shim register करता है
• MIT लाइसेंस

[GN⁺]

Hacker News की राय

• आइडिया बहुत अच्छा है और समझ में आता है। Bun DB driver जैसी चीज़ें और भी देता है, लेकिन यह भी तय है कि developer experience इसकी बड़ी आकर्षक बातों में से एक है
  वैसे, Nub के मुख्य लेखक Zod बनाने वाले Colin McDonnell हैं, और वे पहले Bun में भी काम कर चुके हैं

  • सही। Nub जानबूझकर Nub-विशेष API बिल्कुल नहीं जोड़ता: न कोई Nub global object, न nub: prefix वाले built-in modules, न Nub नाम की config file/lockfile, न package.json में nub field, और न NUB_ environment variables
    Bun ने जो ज़्यादातर चीज़ें जोड़ी हैं, मेरा मानना है कि उन्हें proper dependency के रूप में रखना बेहतर है

• --require hook का इस्तेमाल करना, --import की बजाय, थोड़ा surprising है। हो सकता है जब मैं ऐसा ही कुछ बनाने के लिए देख रहा था तब से बहुत कुछ बदल गया हो, लेकिन लगता है कि Nub के ESM support में कोई सूक्ष्म पहलू हो सकता है
  उस समय Node का --import बहुत शुरुआती अवस्था में था, और आम ESM-to-CJS approach में कई ऐसे exceptions थे जिन्हें संभालना पड़ता था। उनमें से ज़्यादातर शायद बहुत niche cases रहे होंगे, लेकिन मुझे लगता है कि top-level await कुछ महत्वपूर्ण users को प्रभावित करेगा

  • यह सिर्फ़ performance की वजह से preload registration के लिए इस्तेमाल होता है। इस मामले में और कई अन्य मामलों में CommonJS अभी भी ESM से तेज़ है। --require का overhead लगभग 0.5ms है, जबकि --import M1 Macbook Pro पर लगभग 4.6ms है
    इसी संदर्भ में, Node.js ने हाल ही में 2025 में पुराने async module.register() API की तुलना में performance सुधारने के लिए resolver hook registration API का sync version module.registerHooks() पेश किया। Nub के लिए यह एक बड़ा blocker हटने जैसा था। रुचि रखने वालों के लिए, async API में 19ms का fixed registration overhead था और हर import पर लगभग 130us का अतिरिक्त overhead जुड़ता था
    यहाँ Nub कौन-सा flag इस्तेमाल करता है, इसका user code पर बिल्कुल असर नहीं पड़ता, और top-level await वहाँ supported है जहाँ Node.js खुद इसे support करता है

• हमने अभी अपना पूरा monorepo nub पर migrate करने वाला PR merge किया है
  शून्य समस्याएँ, और बेहिसाब तेज़

  • क्या यह पोस्ट होने के एक घंटे के भीतर ही आपने shared monorepo को इस पर migrate करने वाला PR merge कर दिया?

• क्या Node कुछ versions पहले से TypeScript चला नहीं सकता था? फिर transformer की ज़रूरत क्यों है?

  • Node का built-in TypeScript support सिर्फ़ type stripping करता है। यह TypeScript syntax के काफ़ी हिस्से पर काम करता है, लेकिन सब पर नहीं। यह types को वास्तव में check भी नहीं करता, बस उन्हें हटाता है ताकि code चल सके। tsconfig जैसी चीज़ें भी खो जाती हैं
    लगता है यह built-in stripping approach और actual TypeScript processing, दोनों को support करता है
  • Node.js टीम ने Node.js v26 में --experimental-transform-types हटा दिया। इससे native पूर्ण TypeScript support असंभव हो जाता है
    https://github.com/nodejs/typescript/issues/51#issuecomment-...
  • लिखा है कि ज़रूरत पड़ने पर Worker, Temporal जैसी APIs के लिए polyfill inject करता है

• README में लिखा है कि WebSocket support Node 22 से native है, लेकिन Node में native WebSocket library नहीं है। WebSocket standard का link MDN पर जाता है, और वहाँ सिर्फ़ WHATWG user interface समझाया गया है, protocol या WebSocket के काम करने का तरीका नहीं
  लगता है कुछ छूटा हुआ है, या फिर सहारे के लिए कोई non-native library इस्तेमाल हो रही है

  • Node 22 से built-in WebSocket client support करता है, लेकिन server नहीं

• यह सराहनीय है कि यह मौजूदा technology को अपनाता है और उसका बदतर version फिर से नहीं बनाता। अगर alternatives बनाने में लगी सारी मेहनत Node में जाती, तो सही leadership के तहत हम आज कहाँ तक पहुँच गए होते, यह सोचता हूँ

  • आपको 2014 का Node.js io.js fork याद हो सकता है। जब Node ठहर गया था, तो कई लोगों ने io.js में fork किया, जो अंततः फिर Node में merge हो गया और Node को वापस सही दिशा में ले आया। और पीछे जाएँ तो CoffeeScript, जो JS का एक तरह का “fork” था, उसके बेहतरीन ideas भी ES5 में समा गए
    छोटी और फुर्तीली teams अच्छे ideas साबित कर सकती हैं क्योंकि failure उनके लिए घातक जोखिम नहीं होता। संक्षेप में, fork एक healthy ecosystem का हिस्सा हैं
  • बुनियादी तौर पर, इस approach से बहुत-सी चीज़ें ठीक ही नहीं की जा सकतीं
    सरल उदाहरण के तौर on, Node मेरी जानकारी में एकमात्र गंभीर open source software है जिसमें config file के अंदर config को document करने का कोई तरीका नहीं है। यह बेतुका है। Node वालों ने बिना ज़्यादा सोचे JSON अपना लिया, और उसके बाद “JSON with comments” समेत किसी भी alternative पर विचार करने से इनकार कर दिया
    जब कोई संगठन बुरे फैसलों में फँस जाता है, तो उसे ठीक करने का एकमात्र तरीका नए सिरे से शुरू करना होता है। जब तक हर कोई Node के ऊपर ही बनाता रहेगा, पूरा JS ecosystem config में documentation नहीं छोड़ पाएगा
    Node ecosystem में ऐसी कई समस्याएँ हैं, और config को document न कर पाना बस मेरी निजी चिढ़ का एक बड़ा बिंदु है

• मैं Nub और उसके mascot nubnub का fan हूँ। गंभीरता से कहूँ तो यह शानदार project है, और इतना दिलचस्प है कि मैं इसे पिछले हफ्ते से, कम से कम public होने के बाद से, लगातार आज़मा रहा हूँ

• चालाकी भरा। अगर यह पहले से ही Rust में लिखा है, तो इसे Rust में migrate करने की vibe coding करते-करते सारे customers खोने का खतरा नहीं रहेगा ;)

  • OpenAI द्वारा acquire होने के बाद शायद अगला project Zig में rewrite होगा
  • इस project में पहले से ही vibe coding का बड़ा हिस्सा है। repository का दूसरा सबसे बड़ा contributor Claude है
  • “अगर यह पहले से Rust में vibe coded है” शायद ज़्यादा ठीक होगा। Nub में कुल मिलाकर वैसी feeling काफ़ी आती है। ठीक है, लेकिन Bun के साथ तुलना करो तो मज़ेदार लगता है
    जोड़ूँ तो, Bun के खिलाफ़ anti-AI hysteria बहुत दुखद है, और कभी-कभी तो यह संगठित campaign जैसा भी लगता है
  • अगर यह शुरू से ही vibe coded हो और customers भी न हों, तो और मदद मिलती है
  • सही। मुझे समझ नहीं आता कि यहाँ “Rust में लिखा” होने से क्या अतिरिक्त फ़ायदा मिलता है। मुझे तो लगा कि वही काम कुछ shell scripts और package.json से भी किया जा सकता था