Nub - ชุดเครื่องมือแบบออลอินวันที่คล้าย Bun สำหรับ Node.js

 (github.com/nubjs)
2 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ชุดเครื่องมือแบบออลอินวันที่เสริมความสามารถโดยไม่แทนที่ Node.js เขียนด้วย Rust และมอบประสบการณ์พัฒนาแบบคล้าย Bun บน node มาตรฐาน
  • รวมการรันไฟล์·สคริปต์ การติดตั้ง dependencies และการจัดการเวอร์ชัน Node ไว้ในเครื่องมือเดียว โดยไม่มีรันไทม์ใหม่, API เฉพาะผู้ขาย หรือ lock-in
  • File runner nub <file> — รัน .ts, .tsx เป็นต้นได้โดยไม่ต้องมีขั้นตอน build, เข้ากันได้กับ node แบบ flag-for-flag และ var-for-var, startup เร็วกว่า tsx 2.9×
    • รองรับ TypeScript เต็มรูปแบบ (enum, namespace), JSX/TSX, Decorators, โหลด .env* อัตโนมัติ, และมี loader ในตัวสำหรับ .yaml, .toml, .json5 เป็นต้น
    • ตรวจจับและติดตั้งเวอร์ชัน Node ที่โปรเจ็กต์ต้องการโดยอัตโนมัติ (อ้างอิง .node-version, .nvmrc, package.json#engines เป็นต้น)
  • Script runner nub run — ใช้แทน npm/pnpm run ได้แบบ drop-in, เป็นไบนารี Rust ที่ไม่มี JS startup ของตัวเอง ทำให้ dispatch เร็วกว่า pnpm run ราว 24× (14.7ms vs 442.7ms)
    • รองรับครบทั้ง pre/post hook, --filter·--parallel ของ pnpm workspace เป็นต้น
  • Package runner nubx — ใช้แทน npx·pnpm dlx ได้แบบ drop-in, ตัดภาระจากการ spawn Node สองรอบ ทำให้รันได้เร็วกว่า npx ราว 19× (11ms vs 226ms)
  • Package manager nub install — ใช้เอนจิน Aube, เข้ากันได้กับ flag ของ pnpm, เร็วกว่า pnpm 2.5× และเร็วกว่า npm 3.7×
    • มีนโยบายความปลอดภัยเริ่มต้นในตัว — บล็อก postinstall, ตรวจแพ็กเกจอันตรายผ่าน osv.dev, ปฏิเสธ provenance downgrade, และตั้ง minimumReleaseAge ไว้ 24 ชั่วโมง
    • ทำงานในโหมด compat-mode ที่ตรวจจับ lockfile และการตั้งค่าของ npm/pnpm/Yarn/Bun โดยอัตโนมัติ
  • Node version manager nub node — มีคำสั่งจัดการแบบแมนนวล เช่น install·ls·uninstall·pin เวอร์ชัน
  • Package meta-manager nub pm — ทำหน้าที่แบบ Corepack ด้วย native Rust และลงทะเบียน global shim สำหรับ npm·yarn·pnpm
  • สัญญาอนุญาต MIT

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 4 시간 전
ความคิดเห็นจาก Hacker News

  • ไอเดียดีมากและสมเหตุสมผล Bun มีอย่างพวก ไดรเวอร์ฐานข้อมูล เพิ่มมาให้ แต่ก็ชัดเจนว่าส่วนสำคัญของเสน่ห์มันคือประสบการณ์นักพัฒนา
    อ้างอิงไว้ว่า ผู้เขียนหลักของ Nub คือ Colin McDonnell ผู้สร้าง Zod และเคยทำงานที่ Bun มาก่อนด้วย

    • ใช่เลย Nub ตั้งใจไม่ใส่ API เฉพาะของ Nub เลย: ไม่มี global object ของ Nub, ไม่มี built-in module ที่ขึ้นต้นด้วย nub:, ไม่มีไฟล์คอนฟิก/lock file ที่ใช้ชื่อ Nub, ไม่มีฟิลด์ nub ใน package.json, และไม่มีตัวแปรสภาพแวดล้อม NUB_
      ผมคิดว่าสิ่งที่ Bun เพิ่มเข้ามาส่วนใหญ่ควรปล่อยให้เป็น dependency ปกติมากกว่า

  • น่าแปลกที่ใช้ hook ของ --require แทน --import อาจมีอะไรเปลี่ยนไปมากจากตอนที่ผมเคยดูเพื่อทำฟังก์ชันคล้ายกัน แต่สงสัยว่าการรองรับ ESM ของ Nub น่าจะมีรายละเอียดจุกจิกบางอย่าง
    ตอนนั้น --import ของ Node ยังอยู่ช่วงแรกมาก และมีข้อยกเว้นหลายอย่างที่อยากจัดการในแนวทาง ESM-to-CJS แบบที่พบบ่อย แม้ส่วนใหญ่คงเป็นเคสเฉพาะทางมาก แต่ผมคิดว่า top-level await น่าจะกระทบผู้ใช้บางส่วนที่สำคัญ

    • อันนี้ใช้สำหรับการลงทะเบียน preload ด้วยเหตุผลเรื่อง ประสิทธิภาพ ล้วน ๆ ในกรณีนี้และอีกหลายกรณี CommonJS ยังเร็วกกว่า ESM. --require มี overhead ราว 0.5ms ส่วน --import อยู่ที่ประมาณ 4.6ms บน M1 Macbook Pro
      ในประเด็นนี้ Node.js เพิ่งเพิ่ม module.registerHooks() เข้ามาในปี 2025 ซึ่งเป็น API แบบ synchronous สำหรับลงทะเบียน resolver hook เพื่อให้เร็วกว่า API เดิมแบบ asynchronous module.register() นี่ช่วยปลดล็อกอุปสรรคใหญ่ของ Nub ไปได้ สำหรับคนที่สนใจ ขอเสริมว่า API แบบ async มี fixed registration overhead 19ms และเพิ่ม overhead อีกราว 130us ต่อ import
      ธงที่ Nub ใช้ตรงนี้ไม่ส่งผลกับโค้ดของผู้ใช้เลย และ top-level await ก็รองรับทุกที่ที่ Node.js รองรับอยู่แล้ว

  • เราเพิ่ง merge PR ที่ ย้ายทั้ง monorepo ไปใช้ nub
    ไม่มีปัญหาเลยสักอย่าง และเร็วแบบเหลือเชื่อ

    • หมายถึง merge PR ที่ย้าย shared monorepo ไปใช้ตัวนี้ภายในไม่ถึงหนึ่งชั่วโมงหลังโพสต์นี้ขึ้นเหรอ?

  • Node รัน TypeScript ได้มาตั้งแต่หลายเวอร์ชันก่อนแล้วไม่ใช่เหรอ? แล้วทำไมยังต้องมีตัวแปลงอีก?

    • การรองรับ TypeScript ในตัวของ Node ทำแค่ ลบ type ออก มันผ่านกับไวยากรณ์ TypeScript ได้เยอะมาก แต่ไม่ใช่ทั้งหมด และมันก็ไม่ได้ตรวจ type จริง ๆ แค่ลบออกเพื่อให้รันได้ แถมยังเสียสิ่งอย่าง tsconfig ไปด้วย
      อันนี้ดูเหมือนจะรองรับทั้งแนวทางลบออกแบบในตัวและการประมวลผล TypeScript แบบจริงจัง
    • ทีม Node.js เอา --experimental-transform-types ออกจาก Node.js v26 แล้ว แบบนี้ก็ทำให้ การรองรับ TypeScript แบบสมบูรณ์ในระดับเนทีฟ เป็นไปไม่ได้
      https://github.com/nodejs/typescript/issues/51#issuecomment-...
    • เขียนไว้ว่าจะ inject polyfill ให้ถ้าจำเป็นสำหรับ API อย่าง Worker, Temporal

  • ใน README เขียนว่ารองรับ WebSocket แบบเนทีฟตั้งแต่ Node 22 แต่ Node ไม่มีไลบรารี WebSocket แบบเนทีฟ ลิงก์มาตรฐาน WebSocket ก็พาไป MDN ซึ่งอธิบายแค่ส่วนติดต่อผู้ใช้แบบ WHATWG ไม่ได้อธิบายโปรโตคอลหรือวิธีทำงานของ WebSocket
    เหมือนมีอะไรตกหล่นไป หรือไม่ก็รู้สึกเหมือนกำลังใช้ ไลบรารีที่ไม่เนทีฟ มาช่วย

    • Node รองรับ WebSocket client ในตัวตั้งแต่ 22 แต่ยังไม่รองรับ server

  • น่านับถือที่ยอมรับเทคโนโลยีเดิมและไม่สร้างเวอร์ชันที่แย่กว่าขึ้นมาใหม่ ถ้าความพยายามทั้งหมดที่ลงไปกับการสร้างทางเลือกถูกเทไปที่ Node เอง ภายใต้ผู้นำที่เหมาะสม ผมก็สงสัยว่าตอนนี้มันจะไปได้ไกลแค่ไหนแล้ว

    • คุณอาจจำ fork ชื่อ io.js ของ Node.js ในปี 2014 ได้ ตอนนั้น Node หยุดนิ่ง คนจำนวนหนึ่งเลย fork ไปทำ io.js แล้วสุดท้ายก็ merge กลับเข้า Node ทำให้ Node กลับมาเข้าที่เข้าทางอีกครั้ง ถ้าย้อนกลับไปอีก CoffeeScript ซึ่งเป็น “fork” ของ JS ก็มีไอเดียที่ดีที่สุดหลายอย่างถูกดูดซึมเข้า ES5
      ทีมเล็กและคล่องตัวสามารถพิสูจน์ไอเดียดี ๆ ได้ เพราะความล้มเหลวไม่ใช่ความเสี่ยงร้ายแรง พูดสั้น ๆ คือ fork เป็นส่วนหนึ่งของระบบนิเวศที่ดีต่อสุขภาพ
    • โดยพื้นฐานแล้วมีหลายอย่างที่แก้ด้วยแนวทางแบบนี้ไม่ได้
      ตัวอย่างง่าย ๆ คือ Node เป็นซอฟต์แวร์โอเพนซอร์สจริงจังเพียงตัวเดียวเท่าที่ผมรู้ ที่ ไม่มีทางเอกสารคอนฟิกไว้ในไฟล์คอนฟิกได้ มันเหลือเชื่อมาก ฝั่ง Node รับ JSON มาใช้แบบไม่คิดมาก แล้วหลังจากนั้นก็ปฏิเสธแม้แต่จะพิจารณาทางเลือกใด ๆ รวมถึง “JSON ที่มีคอมเมนต์”
      เมื่อองค์กรยึดติดกับการตัดสินใจที่แย่ วิธีเดียวที่จะแก้คือเริ่มใหม่ ตราบใดที่ทุกคนยังคงสร้างต่อบน Node ระบบนิเวศ JS ทั้งหมดก็จะไม่สามารถทิ้งเอกสารกำกับไว้ในคอนฟิกได้
      ระบบนิเวศ Node มีปัญหาแบบนี้อีกหลายอย่าง และความไร้เหตุผลเต็มขั้นที่เอกสารกำกับคอนฟิกไม่ได้ก็เป็นเพียงจุดที่ผมหงุดหงิดเป็นการส่วนตัว

  • เป็นแฟนของ Nub และมาสคอต nubnub พูดจริง ๆ ว่าเป็นโปรเจ็กต์ที่ยอดเยี่ยม และก็น่าสนใจมากจนผมลองใช้มาตลอดตั้งแต่สัปดาห์ก่อน หรืออย่างน้อยก็ตั้งแต่เปิดตัวสาธารณะ

  • ฉลาดดี อย่างน้อยถ้าเขียนด้วย Rust อยู่แล้ว ก็ไม่ต้องเสี่ยงย้ายไป Rust แบบ vibe coding แล้วเสียลูกค้าไปหมด ;)

    • เดี๋ยวพอถูก OpenAI ซื้อไปก็คงย้ายโปรเจ็กต์ไป Zig
    • โปรเจ็กต์นี้เองก็มีสัดส่วนของ vibe coding สูงอยู่แล้ว ผู้มีส่วนร่วมอันดับสองของ repo คือ Claude
    • น่าจะดีกว่าถ้าพูดว่า “ถ้าเขียนด้วย Rust แบบ vibe coding อยู่แล้ว” เพราะ Nub โดยรวมก็มีกลิ่นแบบนั้นพอสมควร ก็ไม่ได้แย่นะ แต่พอเทียบกับ Bun แล้วมันก็ตลกดี
      เสริมอีกนิด กระแสต่อต้าน AI แบบฮิสทีเรียของ Bun น่าเศร้ามาก และบางครั้งก็ให้ความรู้สึกเหมือนเป็นแคมเปญที่จัดตั้งขึ้นมา
    • ที่จริงถ้ามันถูก vibe coding มาตั้งแต่แรกและยังไม่มีลูกค้าเลย ก็ยิ่งช่วยเข้าไปอีก
    • ใช่ ผมไม่ค่อยเข้าใจว่า “เขียนด้วย Rust” ตรงนี้เพิ่มอะไรเข้ามา ผมคิดว่าฟังก์ชันแบบเดียวกันนี้ทำได้ด้วย shell script ไม่กี่ตัวกับ package.json