Nub - bộ công cụ all-in-one kiểu Bun cho Node.js

 (github.com/nubjs)
2 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Bộ công cụ all-in-one bổ trợ chứ không thay thế Node.js, được viết bằng Rust và mang lại trải nghiệm phát triển tương tự Bun trên node tiêu chuẩn
  • Hợp nhất một công cụ duy nhất để chạy tệp·lệnh script, cài đặt dependency và quản lý phiên bản Node, không có runtime mới, API phụ thuộc nhà cung cấp hay lock-in
  • File runner nub <file> — chạy .ts, .tsx... mà không cần bước build, tương thích node từng flag một và từng biến một, khởi động nhanh hơn tsx 2,9×
    • Hỗ trợ TypeScript đầy đủ (enum, namespace), JSX/TSX, Decorators, tự động nạp .env*, loader tích hợp cho .yaml, .toml, .json5...
    • Tự động phát hiện và cài đặt phiên bản Node mà dự án yêu cầu (tham chiếu .node-version, .nvmrc, package.json#engines...)
  • Script runner nub run — thay thế trực tiếp cho npm/pnpm run, là binary Rust không có JS startup riêng nên dispatch nhanh hơn khoảng 24× so với pnpm run (14.7ms vs 442.7ms)
    • Hỗ trợ đầy đủ pre/post hook, pnpm workspace --filter, --parallel...
  • Package runner nubx — thay thế trực tiếp cho npx và pnpm dlx, loại bỏ chi phí double-Node-spawn nên chạy nhanh hơn npx khoảng 19× (11ms vs 226ms)
  • Package manager nub install — dựa trên engine Aube, tương thích flag với pnpm, nhanh hơn pnpm 2,5× và nhanh hơn npm 3,7×
    • Tích hợp chính sách bảo mật mặc định — chặn postinstall, kiểm tra gói độc hại qua osv.dev, từ chối provenance downgrade, minimumReleaseAge 24 giờ
    • Chạy ở compat-mode để tự động phát hiện lockfile và cấu hình của npm/pnpm/Yarn/Bun
  • Node version manager nub node — cung cấp các lệnh quản lý thủ công như install, ls, uninstall, pin phiên bản
  • Package meta-manager nub pm — đảm nhiệm vai trò của Corepack bằng Rust native, đăng ký global shim cho npm, yarn, pnpm
  • Giấy phép MIT

Bài viết liên quan

1 bình luận

 
GN⁺ 4 giờ trước
Ý kiến trên Hacker News

  • Ý tưởng này rất hay và hợp lý. Bun có cung cấp thêm những thứ như driver DB, nhưng rõ ràng trải nghiệm lập trình viên cũng là một phần rất lớn trong sức hút của nó
    Nhân tiện, tác giả chính của Nub là Colin McDonnell, người tạo ra Zod, và từng làm việc tại Bun

    • Đúng vậy. Nub cố ý không thêm bất kỳ API dành riêng cho Nub nào: không có đối tượng toàn cục Nub, không có mô-đun tích hợp với tiền tố nub:, không có file cấu hình/file khóa nào mang tên Nub, không có trường nub trong package.json, cũng không có biến môi trường NUB_
      Tôi nghĩ phần lớn những gì Bun thêm vào sẽ tốt hơn nếu được để thành dependency đúng nghĩa

  • Hơi bất ngờ khi họ dùng hook --require thay vì --import. Có thể mọi thứ đã thay đổi nhiều kể từ lúc tôi xem xét để làm tính năng tương tự, nhưng tôi vẫn nghi Nub có vài điểm tinh tế trong hỗ trợ ESM
    Khi đó --import của Node còn rất sơ khai, và có khá nhiều trường hợp ngoại lệ mà cách tiếp cận ESM-to-CJS phổ biến muốn xử lý. Có lẽ phần lớn là trường hợp rất ngách, nhưng tôi nghĩ top-level await sẽ ảnh hưởng đến một số người dùng đáng kể

    • Cái này được dùng cho đăng ký preload hoàn toàn vì hiệu năng. Trong trường hợp này và nhiều trường hợp khác, CommonJS vẫn nhanh hơn ESM. --require có overhead khoảng 0.5ms, còn --import là khoảng 4.6ms trên M1 Macbook Pro
      Liên quan đến chuyện này, Node.js gần đây trong năm 2025 đã giới thiệu module.registerHooks(), một phiên bản đồng bộ của API đăng ký hook resolver, để cải thiện hiệu năng so với API module.register() bất đồng bộ cũ. Đây là một trở ngại lớn được gỡ bỏ với Nub. Nói thêm cho ai quan tâm: API bất đồng bộ thêm overhead đăng ký cố định 19ms cùng khoảng 130us overhead bổ sung cho mỗi lần import
      Việc Nub dùng cờ nào ở đây hoàn toàn không ảnh hưởng đến mã của người dùng, và top-level await vẫn được hỗ trợ ở những nơi Node.js tự hỗ trợ

  • Tôi vừa merge một PR để migrate toàn bộ monorepo của chúng tôi sang nub
    Không gặp vấn đề nào, và nhanh đến mức vô lý

    • Ý là chỉ trong vòng một giờ sau khi thứ này được đăng lên, bạn đã merge một PR migrate monorepo dùng chung sang cái này à?

  • Chẳng phải Node đã chạy được TypeScript từ vài phiên bản trước rồi sao? Vậy cần bộ chuyển đổi làm gì?

    • Hỗ trợ TypeScript tích hợp sẵn của Node chỉ làm xóa kiểu. Nó xử lý được rất nhiều cú pháp TypeScript, nhưng không phải tất cả. Nó cũng không thực sự kiểm tra kiểu, chỉ loại bỏ để mã có thể chạy. Bạn cũng mất luôn những thứ như tsconfig
      Có vẻ cái này hỗ trợ cả cách xóa tích hợp lẫn xử lý TypeScript thực thụ
    • Nhóm Node.js đã bỏ --experimental-transform-types trong Node.js v26. Điều này khiến hỗ trợ TypeScript đầy đủ ở mức native trở nên bất khả thi
      https://github.com/nodejs/typescript/issues/51#issuecomment-...
    • Có nói là nếu cần cho các API như Worker, Temporal thì sẽ tiêm polyfill

  • README nói hỗ trợ WebSocket là native từ Node 22, nhưng Node không có thư viện WebSocket native. Liên kết chuẩn WebSocket lại dẫn sang MDN, mà bên đó chỉ giải thích giao diện WHATWG cho người dùng chứ không mô tả giao thức hay cách WebSocket hoạt động
    Có vẻ như đang thiếu gì đó, hoặc là họ dùng một thư viện không native để hỗ trợ

    • Từ Node 22, Node có hỗ trợ WebSocket client tích hợp, nhưng không hỗ trợ server

  • Đáng tôn trọng ở chỗ nó chấp nhận công nghệ hiện có thay vì làm lại một phiên bản tệ hơn. Nếu toàn bộ nỗ lực đổ vào việc tạo lựa chọn thay thế được dồn cho Node, tôi tự hỏi dưới sự dẫn dắt phù hợp thì giờ nó đã tiến xa đến đâu

    • Có thể bạn còn nhớ bản fork io.js của Node.js năm 2014. Khi Node bị đình trệ, nhiều người đã fork sang io.js, rồi cuối cùng nó được hợp nhất trở lại vào Node và đưa Node trở lại đúng quỹ đạo. Xa hơn nữa, CoffeeScript, một “bản fork” của JS, cũng đã có những ý tưởng hay nhất được hấp thụ vào ES5
      Các nhóm nhỏ và linh hoạt có thể chứng minh những ý tưởng hay vì thất bại không phải rủi ro chí mạng. Nói ngắn gọn, fork là một phần của hệ sinh thái lành mạnh
    • Về căn bản, có nhiều thứ không thể sửa bằng cách tiếp cận kiểu này
      Ví dụ đơn giản nhất là Node là phần mềm mã nguồn mở nghiêm túc duy nhất mà tôi biết không có cách nào để ghi tài liệu cho cấu hình ngay trong file cấu hình. Thật vô lý. Phía Node đã hấp tấp chọn JSON, rồi sau đó từ chối xem xét bất kỳ lựa chọn thay thế nào, kể cả “JSON có chú thích”
      Khi một tổ chức bị kẹt cứng vào quyết định tồi, cách duy nhất để sửa là bắt đầu lại từ đầu. Chừng nào mọi người vẫn tiếp tục chồng thêm lên Node, toàn bộ hệ sinh thái JS sẽ không thể để lại tài liệu trong phần cấu hình
      Hệ sinh thái Node có khá nhiều vấn đề như vậy, và sự phi lý tuyệt đối của việc không thể ghi tài liệu cho cấu hình chỉ là điểm khiến cá nhân tôi bực nhất

  • Tôi là fan của Nub và linh vật nubnub. Nói nghiêm túc thì đây là một dự án rất tốt, khá thú vị, và tôi đã dùng thử từ tuần trước, hoặc ít nhất là từ khi nó được công khai

  • Thông minh đấy. Vì nếu đã được viết bằng Rust rồi thì sẽ không có chuyện migrate sang Rust bằng vibe coding rồi làm mất sạch khách hàng ;)

    • Chắc sau khi bị OpenAI thâu tóm thì dự án tiếp theo sẽ đổi sang Zig
    • Dự án này vốn đã có tỷ lệ vibe coding khá cao. Người đóng góp lớn thứ hai trong repo là Claude
    • Có lẽ nói “nếu đã được vibe code bằng Rust rồi” sẽ hợp hơn. Nhìn chung Nub khá có mùi đó. Không sao cả, nhưng đặt cạnh Bun thì cũng buồn cười
      Nói thêm thì cơn cuồng chống AI của Bun thật sự rất đáng buồn, đôi lúc còn có cảm giác như một chiến dịch có tổ chức
    • Nếu ngay từ đầu đã được vibe code và cũng không có khách hàng nào, thì còn hữu ích hơn nữa
    • Đúng vậy. Tôi không rõ việc “viết bằng Rust” bổ sung được gì ở đây. Tôi nghĩ cùng chức năng đó cũng có thể làm bằng vài shell script và package.json