Nub - Node.js向けのBunライクなオールインワンツールキット

 (github.com/nubjs)
2 ポイント 投稿者 GN⁺ 5 시간 전 | 1件のコメント | WhatsAppで共有
  • Node.jsを置き換えるのではなく補完するオールインワンツールキットで、Rustで書かれており標準のnode上でBunに近い開発体験を提供
  • ファイル・スクリプト実行、依存関係のインストール、Nodeバージョン管理を単一ツールに統合し、新しいランタイム・ベンダー依存API・lock-inなし
  • File runner nub <file> — .ts、.tsxなどをビルド工程なしで実行し、nodeとflag-for-flag・var-for-var互換、tsx比で起動が2.9倍高速
    • 完全なTypeScriptサポート（enum、namespace）、JSX/TSX、Decorators、.env*自動読み込み、.yaml・.toml・.json5などの組み込みloader
    • プロジェクトが想定するNodeバージョンの自動検出・インストール（.node-version、.nvmrc、package.json#enginesなどを参照）
  • Script runner nub run — npm/pnpm runのdrop-inで、独自のJS startupがないRustバイナリによりpnpm run比で約24倍高速なdispatch（14.7ms vs 442.7ms）
    • pre/post hook、pnpm workspaceの--filter・--parallelなどを全面サポート
  • Package runner nubx — npx・pnpm dlxのdrop-inで、double-Node-spawnペナルティを除去しnpx比で約19倍高速に実行（11ms vs 226ms）
  • Package manager nub install — Aubeエンジンベースで、pnpmとflag互換、pnpm比2.5倍・npm比3.7倍高速
    • デフォルトのセキュリティポリシーを内蔵 — postinstallをブロックし、osv.devの悪意あるパッケージを検査し、provenance downgradeを拒否、24時間のminimumReleaseAge
    • npm/pnpm/Yarn/Bunのlockfile・設定を自動検出するcompat-modeで動作
  • Node version manager nub node — バージョンのinstall・ls・uninstall・pinなどの手動管理コマンドを提供
  • Package meta-manager nub pm — Corepackの役割をnative Rustで担い、npm・yarn・pnpmのグローバルshimを登録
  • MITライセンス

関連記事

1件のコメント

 
GN⁺ 5 시간 전
Hacker Newsのコメント

  • アイデアはとても良く、筋が通っている。Bun は DBドライバ などをさらに提供しているが、開発者体験も魅力の大きな部分であることは確かだ
    ちなみに Nub の主著者は Zod を作った Colin McDonnell で、かつて Bun でも働いていた

    • その通り。Nub は意図的に Nub 専用 API を一切追加していない。Nub のグローバルオブジェクトも、nub: 接頭辞付きの組み込みモジュールも、Nub という名前の設定ファイルやロックファイルも、package.json の nub フィールドも、NUB_ 環境変数もない
      Bun が追加したものの大半は、きちんとした依存関係として持つほうがよいと思う

  • --import ではなく --require フックを使っているのは意外だ。同様の機能を作ろうとして調べていた頃から何か大きく変わったのかもしれないが、Nub の ESM サポートには微妙な点があるのではないかと思う
    当時は Node の --import がまだかなり初期段階で、一般的な ESM-to-CJS アプローチで対処したかった例外がいくつもあった。その大半はかなりニッチなケースだっただろうが、トップレベル await は一部の重要なユーザーに影響すると考えていた

    • これは純粋に 性能 のためにプリロード登録で使っている。このケースや他の多くのケースでも、CommonJS は依然として ESM より速い。--require のオーバーヘッドは約 0.5ms だが、--import は M1 Macbook Pro で 4.6ms ほどだ
      関連して Node.js は最近 2025 年に、以前の非同期 module.register() API より性能を高めるため、resolver フック登録 API の同期版である module.registerHooks() を導入した。これは Nub にとって大きな障害の解消だった。関心のある人向けに付け加えると、非同期 API は固定の登録オーバーヘッド 19ms に加え、import ごとに約 130us の追加オーバーヘッドがあった
      ここで Nub がどのフラグを使っているかはユーザーコードにまったく影響せず、トップレベル await も Node.js 自体が対応している場所ではサポートされる

  • ちょうど モノレポ全体を nub に移行する PR をマージしたところだ
    問題は 0 件で、信じられないほど速い

    • これが投稿されてから 1 時間もしないうちに、共有モノレポをこれに移行する PR をマージしたってこと？

  • Node は数バージョン前から TypeScript を実行できたのでは？ なぜトランスパイラが必要なんだ？

    • Node の組み込み TypeScript サポートは 型の削除しか行わない。TypeScript 文法のかなり多くの部分には通用するが、全部ではない。型を実際に検査することもなく、実行できるように取り除くだけだ。tsconfig のようなものも失われる
      これは組み込みの削除方式と、実際の TypeScript 処理の両方をサポートしているようだ
    • Node.js チームは Node.js v26 で --experimental-transform-types を削除した。これではネイティブな 完全 TypeScript サポート は不可能になる
      https://github.com/nodejs/typescript/issues/51#issuecomment-...
    • Worker や Temporal のような API に必要であれば ポリフィルを注入すると書かれている

  • README には WebSocket サポートは Node 22 からネイティブと書かれているが、Node にはネイティブの WebSocket ライブラリはない。WebSocket 標準へのリンクは MDN に飛ぶが、そこでは WHATWG のユーザーインターフェースしか説明されておらず、プロトコルや WebSocket の動作については説明していない
    何かが欠けているか、補助として 非ネイティブのライブラリを使っているように感じる

    • Node は 22 から組み込みの WebSocket クライアント をサポートしているが、サーバーはサポートしていない

  • 既存技術を受け入れ、より悪いバージョンを作り直さない点は評価できる。代替を作るために費やされたすべての労力が Node に向けられていたら、適切なリーダーシップの下で今ごろどこまで進んでいたのか気になる

    • 2014 年の Node.js の io.js フォークを覚えているかもしれない。Node が停滞すると多くの人が io.js にフォークし、最終的には Node に再統合されて Node を本来の軌道に戻した。さらにさかのぼれば、JS の「フォーク」だった CoffeeScript も、最高のアイデアが ES5 に取り込まれた
      小さく機敏なチームは、失敗が致命的なリスクではないため、良いアイデアを実証できる。要するにフォークは健全なエコシステムの一部だ
    • 根本的に、このアプローチでは直せないものが多い
      簡単な例を挙げると、Node は私が知る本格的なオープンソースソフトウェアの中で 設定ファイル内に設定を文書化する方法がない 唯一のものだ。ばかげている。Node 側は深く考えずに JSON を採用し、その後は「コメント付き JSON」すら含め、どんな代替案の検討も拒んできた
      組織が悪い決定に固執したとき、それを直す唯一の方法はゼロからやり直すことだ。皆が Node の上に積み上げ続ける限り、JS エコシステム全体は設定に説明を書き残せないままだろう
      Node エコシステムにはこうした問題がいくつもあり、設定を文書化できないという完全な不条理は、ただの個人的な不満点にすぎない

  • Nub とマスコットの nubnub のファンだ。真面目な話、素晴らしいプロジェクトで、かなり興味深いので先週から、少なくとも公開されて以来ずっと試している

  • うまい。すでに Rust で書かれていれば、Rust への移行をバイブコーディングしているうちに顧客を全部失うこともないからね ;)

    • OpenAI に買収されたら、次はプロジェクトを Zig に変えそう
    • このプロジェクトはすでに バイブコーディング の比率が高い。リポジトリの 2 番目の貢献者は Claude だ
    • 「すでに Rust でバイブコーディングされているなら」のほうがよさそう。Nub 全体からかなりそういう匂いがする。別に悪くはないが、Bun と比べると笑ってしまう
      付け加えると、Bun に対する反 AI ヒステリーはとても悲しく、ときには組織的なキャンペーンのように感じることすらある
    • そもそもすでにバイブコーディングされていて顧客もいないなら、なおさら都合がいい
    • そうだね。ここで「Rust で書かれている」ことが何を付け加えるのかはよくわからない。同じ機能はシェルスクリプト数本と package.json でも実現できると思っていた