Hacker News: colinmcd

New comment by colinmcd in "Show HN: Nub – A Bun-like all-in-one toolkit for Node.js"

colinmcd — Wed, 24 Jun 2026 22:40:27 +0000

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.

New comment by colinmcd in "Show HN: Nub – A Bun-like all-in-one toolkit for Node.js"

colinmcd — Wed, 24 Jun 2026 19:31:05 +0000

Certainly. We're using subtrees now instead of submodules, lets avoids some tricky worktree/submodule interactions during local dev.

We've already pulled changes since that PR landed.

https://github.com/nubjs/nub/commit/b4abee87

New comment by colinmcd in "Show HN: Nub – A Bun-like all-in-one toolkit for Node.js"

colinmcd — Wed, 24 Jun 2026 19:23:44 +0000

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.)

New comment by colinmcd in "Show HN: Nub – A Bun-like all-in-one toolkit for Node.js"

colinmcd — Wed, 24 Jun 2026 18:52:31 +0000

I almost called it "oi" but I'm not sure anyone would have gotten the joke :P

New comment by colinmcd in "Show HN: Nub – A Bun-like all-in-one toolkit for Node.js"

colinmcd — Wed, 24 Jun 2026 18:46:52 +0000

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.

New comment by colinmcd in "Show HN: Nub – A Bun-like all-in-one toolkit for Node.js"

colinmcd — Wed, 24 Jun 2026 17:39:43 +0000

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.

New comment by colinmcd in "Show HN: Nub – A Bun-like all-in-one toolkit for Node.js"

colinmcd — Wed, 24 Jun 2026 16:39:45 +0000

It entered public beta last week, but just getting on HN now.

New comment by colinmcd in "Show HN: Nub – A Bun-like all-in-one toolkit for Node.js"

colinmcd — Wed, 24 Jun 2026 16:38:49 +0000

Coming very soon!

New comment by colinmcd in "Show HN: Nub – A Bun-like all-in-one toolkit for Node.js"

colinmcd — Wed, 24 Jun 2026 15:26:22 +0000

Thanks :) Highly recommend clicking the link too!

New comment by colinmcd in "Show HN: Nub – A Bun-like all-in-one toolkit for Node.js"

colinmcd — Wed, 24 Jun 2026 15:25:50 +0000

Yep, full support on macOS, Linux, Windows. No official image yet (I'll start on this now) but you can get started with something like this.

  FROM node:26-slim
  RUN npm i -g @nubjs/nub

Works with any Node version down to 18.19 but recommend 22.15+ for best performance (that's when synchronous registerHooks was introduced[0])

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

New comment by colinmcd in "Show HN: Nub – A Bun-like all-in-one toolkit for Node.js"

colinmcd — Wed, 24 Jun 2026 15:17:40 +0000

Cloudflare Workers is a different runtime and has its own toolchain around it. Nub could theoretically support it when executing files (spawn `wrangler dev` instead of `node` if wrangler.toml is detected or something) but really I'm focused on making the Node.js experience as good as possible.

The other pieces of the toolkit could absolutely be used: package manager, script runner, package runner. Works with anything that implements the Node module resolution algorithm (actually Yarn PnP also works out of the box...).

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

colinmcd — Wed, 24 Jun 2026 14:14:18 +0000

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...

Comments URL: https://news.ycombinator.com/item?id=48660267

Points: 200

# Comments: 57

Nub – A Bun-like toolkit that extends Node.js instead of trying to replace it

colinmcd — Tue, 23 Jun 2026 13:44:50 +0000

Article URL: https://github.com/nubjs/nub

Comments URL: https://news.ycombinator.com/item?id=48644902

Points: 3

# Comments: 0

Bolt Cloud

colinmcd — Thu, 14 Aug 2025 17:38:53 +0000

Article URL: https://bolt.new/blog/bolt-cloud

Comments URL: https://news.ycombinator.com/item?id=44903330

Points: 1

# Comments: 0

New comment by colinmcd in "Zod 4"

colinmcd — Tue, 20 May 2025 18:55:50 +0000

As you allude to: your aliased "zod-next" dependency wouldn't be able to satisfy the requirements of any packages with a peer dep on Zod. But this approach has a more fundamental flaw. My goal is to let ecosystem libraries support Zod 3 and Zod 4 simultaneously. There's no reliable way to do that if they aren't in the same package.[0]

[0] https://github.com/colinhacks/zod/issues/4371

New comment by colinmcd in "Zod 4"

colinmcd — Tue, 20 May 2025 18:45:48 +0000

It won't typecheck, which is good in this case, because as you say that's a very bad idea :)

New comment by colinmcd in "Zod 4"

colinmcd — Tue, 20 May 2025 18:40:14 +0000

I understand this as a knee-jerk reaction. I didn't do this lightly.

> Perhaps publish a 4.x along with the 3.x stuff

You have some misconceptions about how npm works. Unfortunately it's less reasonable than you think. There's a single `latest` tag, and there's only one "latest" version at a time. It's expected that successive versions here will follow semver. Once I publish zod@4 I can no longer publish additional zod@3.x.x versions. The workaround here is to publish v3 versions to a separate dist tag (zod@three) but anyone consuming that dist-tag (e.g. "zod": "three" in their package.json) loses the ability to specify a semver range.

I recommend reading the writeup[0]. I don't think you're appreciating the magnitude of the disruption a simple major version bump would have caused, or the reasons why this approach is necessary to unlock continuity for Zod's ecosystem libraries. They're quite subtle.

[0] https://github.com/colinhacks/zod/issues/4371

New comment by colinmcd in "Zod 4"

colinmcd — Tue, 20 May 2025 18:32:40 +0000

No, that kind of interop, especially static interop (assignability), would've been totally unworkable. Despite the length of the changelog, there are very few breaking changes to the user-facing API surface. It's mostly internal/structural changes and deprecations (most of which can be fixed with a find&replace).

Report back about that .d.ts issue. It should be far better. That kind of type explosion usually happens when TypeScript needs to infer function/method return types. Zod 4 uses isolatedDeclarations so this kind of thing shouldn't happen.

New comment by colinmcd in "Zod 4"

colinmcd — Tue, 20 May 2025 07:26:50 +0000

Yes! Zod now differentiates between `z.string().optional()` and `z.union([z.string(), z.undefined()])` (as in TypeScript itself). Details: https://x.com/colinhacks/status/1919291504587137496

New comment by colinmcd in "Zod 4"

colinmcd — Tue, 20 May 2025 07:24:38 +0000

Yep, at some indeterminate point when I gauge that there's sufficient support for Zod 4 in the ecosystem, I'll publish `zod@4.0.0` to npm. This is detailed in the writeup[0]

[0] https://github.com/colinhacks/zod/issues/4371