You can continue using pnpm if you want. Nub is a la carte. Nub's runtime or script runner functionality will work with any package manager that uses node_modules (actually Yarn PnP is also supported out of the box).
You can also move over to Nub from pnpm incrementally if you want the performance or security wins. It has complete pnpm compatibility: flag for flag identical CLI, reads and writes from your pnpm-lock.yaml, and respects your expecting configs completely. Nub and pnpm can be used simultaneously by different teammates without lockfile churn. This is a key design goal, and its what I mean by "incrementally adoptable". But yeah `nub install` will almost certainly work in your repo out of the box. (File an issue otherwise.)
Same is true for npm, yarn, and bun as well. It detects your current package manager (based on package.json#packageManager or lockfile existence) and runs in "compatibility mode" for that specific package manager.
Exactly this. TypeScript also ended up being many users' entrypoint to JSX, decorators, etc as it became a catchall transpiler surface so respecting tsconfig is vital here (Node understandably has a policy against this). Plus there are extensionless imports, the "phantom" .js imports (pointing to .ts files), etc. List goes on. Type stripping ends up working out of the box for virtually no real world projects sadly.
Indeed, Nub intentionally introduces no Nub-specific APIs: no Nub global, no nub: prefixed built-in modules, no Nub-named config file / lockfile, no "nub" field in package.json, not even any NUB_ environment variables. Most of the stuff Bun added is better as a proper dependency imo.
EDIT: Sorry, I understand you're talking about package.json. Would be fun to try to get the Node & package mgmt teams aligned to add support for comments in the package.json. Bun tried and failed to do this (requires ecosystem coordination).
Nub could absolutely support a config file and use it to set NODE_OPTIONS or flags in the node child process. There's no reason to throw out the baby with the bathwater due to DX concerns like this. That's a key part of the concept Nub is trying to prove. (To be clear I'm quite content to conform to Node's no-config-file policy at the moment.)
Right now, you should use Nub on the backend if you are relying on its augmentations. If you specifically want to disable Nub's augmentations (so you have a guarantee that your app/script will "just work" with regular Node, there's a couple ways to disable it.
NODE_COMPAT=0 nub index.ts
nub --node index.ts
I'll investigate a `nub build` that would do the transpilation upfront and properly chunk/bundle a prod build. It's a good idea. But yes, Nub's overhead (both time and space) is generally negligible relative to Node itself.
Re: added attack surface: the most obvious one is that Nub loads .env files (same as Bun/Next/Vite) so be aware of that. All of Node's permission flags are passed through as well. I won't claim there's no additional attack surface, but it doesn't have much surface area, just a Rust wrapper that spawns `node` ultimately.
I'm seeing lots of bots/agents misusing backticks like this. It's because people are writing agent plans in markdown and the agent thinks it's appropriate everywhere. Maybe you shouldn't be running all your comment replies through Claude.
Backticks ` ` are used to trigger code-style formatting in markdown. Since all the coding AIs are trained almost entirely on github, you see it everywhere in their output. They'll use it even in places where it's supposed to be just plain text, and almost always in git log messages, which by spec have no formatting.
i write markdown-ish text in any text box including using backticks for command names like `cat`, or use * for *emphasis* just like i did on IRC in the 2000s. these conventions in human plain text conversation predate markdown and AI by decades. that was the point of markdown: formalizing those kinds of conventions enough to turn them into deterministic rich styling.
HN itself renders * as emphasis, but not ` for "code"; this doesn't mean HN is a broken markdown machine or that i'm a bot. many hn comments use plain text conventions for links, see examples that use footnote style markdown-like links[0], I was [doing markdown links here back in 2017](https://news.ycombinator.com/item?id=14763397) even though they've never been parsed by HN.
This kind of semantic formalism in text goes way back, its not so different from something like Chicago style citations first published in 1906 [1].
Slack uses this? Thanks for the info. I've never been forced into Slack, so I wasn't aware of that. Either way, it's stupid to use in places it doesn't induce formatting.
We use this to register our preload purely for performance reasons. In this and many other cases CommonJS is still faster than ESM. Using --require is about 0.5ms overhead vs 4.6ms for --import (on my M1 Macbook Pro).
Relatedly Node.js recently (2025) introduced a synchronous version of its resolver hook registration API (`module.registerHooks()`) specifically to improve performance over the old async `module.register()` API. It was a big unblocker for Nub. For the interested, the async API added 19ms fixed registration overhead + about 130us additional overhead per import.
Which flag Nub uses here doesn't impact userland at all, TLA is supported wherever it's supported by Node.js itself.
Thanks! From what you say here and what I see in the docs, it looks like everything is much simpler and more robust than when I was exploring the space. I’m happy to see that, and thrilled it’s mature enough now to support use cases like nub.
I will seriously consider migrating once this exists! I couldn’t imagine deploying any other way now. I can never go back from SCPing a single binary to my server and just hitting reset on the service.
You can also move over to Nub from pnpm incrementally if you want the performance or security wins. It has complete pnpm compatibility: flag for flag identical CLI, reads and writes from your pnpm-lock.yaml, and respects your expecting configs completely. Nub and pnpm can be used simultaneously by different teammates without lockfile churn. This is a key design goal, and its what I mean by "incrementally adoptable". But yeah `nub install` will almost certainly work in your repo out of the box. (File an issue otherwise.)
https://nubjs.com/docs/install/pnpm
Same is true for npm, yarn, and bun as well. It detects your current package manager (based on package.json#packageManager or lockfile existence) and runs in "compatibility mode" for that specific package manager.
https://nubjs.com/docs/install#config-it-reads