Show HN: Nub – A Bun-like all-in-one toolkit for Node.js (github.com)

277 points by colinmcd ↗ HN
Colin here, creator of Nub. I’ve had the general shape of this in mind for years. Nub runs your code with stock `node`, augmented with a `--require` preload hook[0] that adds a transpiler (oxc-powered, packaged as a Node-API add-on), registers a module resolution hook[1], and injects polyfills as needed for APIs like `Worker`, `Temporal`, etc. All purely additive, your code ultimately runs using Node’s actual engine & stdlib implementations.

[0] https://nodejs.org/api/cli.html#-require-module

[1] https://nodejs.org/api/module.html#moduleregisterhooksoption...

32 comments

[ 0.48 ms ] story [ 36.6 ms ] thread
(comment deleted)
Just merged a PR migrating our entire monorepo to nub.

0 issues, ridiculously fast.

Nice, I think this fills a niche. Does it work on cloudflare workers?
nice ! does this work on docker containers ?
I didn't even click on the link. I just came to give the author a hat-tip on the project name. Well played.
Very smart. You can't lose all your customers for vibe-coding a migration to Rust if you are already written in Rust ;)
I saw this on twitter and loved it, such a good move on your part Colin. Hope the project picks up tons of steam!
Respect for embracing existing tech instead of rewriting a worse version of it. Wonder where we would be today if all alternative-building effort went to Node instead (with proper leadership).
Love the idea, learning a lot of interesting things about node hooks by reading docs and some code
Nice. Can we get `nub --compile` up in there like Bun has?
I’m surprised to see this using a `--require` hook (rather than `--import`). Maybe something’s changed significantly since I was looking into building some similar functionality… but it makes me wonder about nuances in nub’s ESM support.

(When I was investigating this it was very early in Node’s `--import` story, but there were several edge cases with the more common ESM-to-CJS approaches that I wanted to address. Most were probably exceedingly niche concerns, but I’d expect top-level await to affect a meaningful subset of users.)

> TypeScript-friendly resolution: extensionless imports, tsconfig.json#paths

I’m wondering how that works. Deno has very complicated import resolution, so building my own import resolver to be compatible with it is a bit of a pain. (This is for a custom lint-like tool.)

Am I expected to be able to run this in production on the backend, or do I still need to transpile and bundle? Do we expect the performance and memory overhead to be negligible. What would be the expectations on terms of added attack surface?
I actually really like this! Great choices all around.
Very cool idea which makes a lot of sense. Bun provides more (eg db drivers) but the DX is certainly a big part of its appeal.

For reference, the main author of Nub is Colin McDonnell who created Zod and even worked at Bun at some point.

I know some people who pronounce n00b like nub, which makes this sort of funny to me. (Maybe it's even intentional?)
what's wrong with bun? And how is this better?
for me it’s the segfaults. never had node segfault on me.
This looks fantastic.

One suggestion, for package management you should just wrap pnpm, my desire to move to anything else is nil.

The readme says Websockets support is native from Node 22, except Node does not have a native Websockets library. Their link for Websockets standard goes to MDN, which is fine except that only describes the WHATWG user interface and nothing about the protocol or how Websockets works.

It feels like this is missing something or using a nonnative library as a supplemental addition.

big fan of nub and nubnub the mascot. Seriously though, this is a great project. I'm super intruiged and been using for the past week or at least since it released