Nub is an all-in-one Rust toolkit for Node.js that folds a package manager, script and bin dispatcher, file runner, watcher, and version manager into one binary, Bun-style, while leaving V8 untouched. There is no Nub runtime: code is transpiled in memory via oxc and handed to the stock node binary. The bet is that Bun’s integrated developer experience can be delivered on top of Node rather than against it.
What Nub replaces, and what it deliberately keeps
One Rust binary covers seven categories of tooling: file runners (node, tsx, ts-node, dotenv-cli), script runners (npm run, pnpm run), bin runners (npx, pnpm dlx), installers (npm, pnpm), watchers (nodemon, node --watch), version managers (nvm, fnm, n, volta), and corepack. It is a consolidation play, and it works because Nub keeps the one thing those tools all assume: Node itself.
What it does not do is replace the runtime. Nub’s own framing is blunt: there is “no Nub runtime, just real Node.” Code is transpiled through oxc embedded as an N-API native addon and executed on the unmodified node binary. The Bun-versus-Node framing that has dominated the last two years is a runtime question. Nub reframes it as a toolchain question.
How Nub rides on Node hooks Bun and Deno didn’t have
The technical premise is that Node has grown extension surfaces since Bun and Deno were designed, and those surfaces make a non-runtime toolkit viable. Nub’s README names three that “mostly didn’t exist when Deno and Bun were built”: --import and --require preloads for early hook installation, module.registerHooks() for runtime transpilation and module resolution, and N-API native addons for in-process work.
module.registerHooks() is the load-bearing piece. It lets Nub intercept module loading and transpile TypeScript on the fly, without spawning a separate process or shipping a parser in JavaScript. N-API lets the Rust-based oxc do the heavy lifting in-process as a compiled addon, which is where the speed comes from. The architecture is “augment the runtime you already have,” not “ship a competing runtime and chase parity forever.” The latter is the project Bun and Deno are still grinding through.
How fast is it, and who measured
Nub reports 24× faster script dispatch than pnpm run, 19× faster bin dispatch than npx, and 2.5× faster install than pnpm install. The wins are mechanical: npm and pnpm pay a Node startup tax to resolve and shim a script, while Nub resolves in Rust and skips most of it. The install multiplier is the most aggressive of the three, and the most worth reproducing on Linux before believing.
Node compatibility, by architecture
Nub’s compatibility story is what the architecture predicts. Nub runs on real V8, so anything Node does, Nub mostly does too. The Node-compat surface is inherited rather than reimplemented, which is the structural advantage of refusing to ship a competing runtime: there is no parity gap to chase, and no second engine to drift out of sync with Node’s own test suite.
Why Nub’s “no lock-in” pitch is structural
Nub commits to zero lock-in at the API surface: no Nub global, no nub:* module namespace, no @nub/* npm scope, no nub field in package.json, and no Nub-named lockfile. The installer reads and writes the incumbent lockfile format. npm, pnpm, and Bun lockfiles round-trip cleanly, and yarn is read-only.
That is a stronger claim than Bun’s “drop-in runtime,” because there is nothing to drop in or rip out. A team that adopts Nub and later walks away is left with standard npm, pnpm, or Bun lockfiles and a standard Node project. The migration cost approaches the adoption cost.
The honest qualifier: “no lock-in” is an architectural claim, not a vendor one. Nub is still single-vendor, and ships as one Rust binary. You can swap the lockfile out for an incumbent’s. The engine itself is another matter. For most teams that distinction is fine, but it is the real boundary of the claim.
The ceiling Nub cannot break: Node’s own startup
Nub does not escape Node’s startup overhead. Its own pitch is negligible overhead over plain Node, and 2.9× faster startup than tsx. The speed wins are over JavaScript-based wrappers, not over Node itself. Anyone hoping Nub delivers Bun-throughput on V8 is reading the wrong pitch.
This is the honest core of the tradeoff, and it is worth setting against Bun’s own numbers. Bun’s much-cited hello-world HTTP advantage of around 2.6× (120k vs 45k req/s) shrinks to roughly 3% (12,400 vs 12,000 req/s) once a real workload is layered on, covering databases, ORMs, validation, business logic. If the throughput edge that justifies paying Bun’s compatibility tax is that thin in production, the case for staying on V8 and optimizing the toolchain instead gets stronger.
The compatibility tax is concrete. Because Bun runs on JavaScriptCore rather than V8, native C++ node-gyp modules break. bcrypt, sharp, and sqlite3 are the cited casualties, each needing a JavaScript or WASM replacement. Nub sidesteps that entire class of failure by never leaving V8. The cost is that it also never gets Bun’s event-loop throughput where it genuinely exists.
Who should reach for Nub, and who should not
Nub is a toolchain-consolidation play for teams already on Node who want faster script dispatch and a single-binary CI setup, without betting their dependency tree on a non-V8 runtime. It runs on Node.js 18 LTS and newer, across macOS, Linux, and Windows, and ships nubjs/setup-nub@v0 as a one-to-one swap for actions/setup-node@v4.
It is the wrong tool for anyone whose goal is raw throughput. Nub will not beat Node, because it is Node. It is also the wrong tool for anyone who needs Deno’s permissions model, or whose workload genuinely benefits from Bun’s runtime rather than its CLI.
The framing that lands it: byteiota’s summary of Bun’s production blockers notes teams being forced to reconsider deployments or adopt hybrid approaches. Nub’s contribution is to collapse that hybrid into one toolchain on one runtime, and to bet that the toolchain was the part worth consolidating all along.
Frequently Asked Questions
Where does Nub break Node compatibility, and how many tests fail?
On Deno’s Node-compatibility corpus of 4,368 tests, Nub passes 4,315, with its 53 misses concentrated in two areas: auto-enabling experimental Node features and loading native addons. Stock Node 25.8 passes all 4,368, while Deno 2.8 passes 3,380 and Bun 1.3.14 only 1,770.
What supply-chain defenses does Nub’s installer enable by default?
Nub blocks postinstall scripts on a deny-by-default basis until you run nub approve-builds, queries osv.dev for malicious-package advisories on every fresh resolve, refuses provenance downgrades, and enforces a 24-hour minimumReleaseAge on new releases. All four ship enabled rather than behind a configuration flag.
Does Nub’s installer beat Bun’s, or just npm and pnpm?
Nub claims it does. On a warm frozen create-t3-app install with 222 dependencies, Nub reports 1,122ms versus Bun’s 1,444ms, roughly 29 percent faster, while pnpm takes 2,847ms and npm 4,163ms. That figure is macOS, warm, and vendor-measured, and Bun has historically led install benchmarks, so it warrants independent reproduction before being trusted.
Why does Nub ship its own pm shim instead of relying on Corepack?
Corepack was unbundled from Node in v25, leaving the package-manager-routing job that corepack filled as an open gap in the default Node install. Nub’s pm subcommand shims npm, pnpm, and Bun, routing to the incumbent lockfile format, which closes the hole v25 opened.
What is the minimum Node version for Nub’s augmented modes?
Nub runs on Node 18 LTS and newer, but the augmented modes that hook module loading and transpilation require Node 18.19 or later, when the —import preload and module.registerHooks() surfaces became available. Pre-18.19 installs get the dispatcher and installer but lose the in-process TypeScript transpilation.
