colinmcd

5 ms·

1.
The config file for Node.js you always wanted(nubjs.com)
3 points by colinmcd 1mo ago|0 comments
2.
We built a 5x faster JavaScript package manager(nubjs.com)
2 points by colinmcd 2mo ago|0 comments
3.
Node.js's phantom dependency problem and the path to a 5x faster package manager(nubjs.com)
1 points by colinmcd 2mo ago|0 comments
4.
by colinmcd 3mo ago
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
5.
by colinmcd 3mo ago
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
6.
by colinmcd 3mo ago
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 o
7.
by colinmcd 3mo ago
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&
8.
by colinmcd 3mo ago
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 coor
9.
by colinmcd 3mo ago
I almost called it "oi" but I'm not sure anyone would have gotten the joke :P
10.
by colinmcd 3mo ago
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 No
11.
by colinmcd 3mo ago
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 rece
12.
by colinmcd 3mo ago
It entered public beta last week, but just getting on HN now.
13.
by colinmcd 3mo ago
Coming very soon!
14.
by colinmcd 3mo ago
Thanks :) Highly recommend clicking the link too!
15.
by colinmcd 3mo ago
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
16.
by colinmcd 3mo ago
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 fo
17.
Show HN: Nub – A Bun-like all-in-one toolkit for Node.js(github.com)
277 points by colinmcd 3mo ago|81 comments
18.
Nub – A Bun-like toolkit that extends Node.js instead of trying to replace it(github.com)
3 points by colinmcd 3mo ago|0 comments
19.
Bolt Cloud(bolt.new)
1 points by colinmcd 1y ago|0 comments
20.
by colinmcd 1y ago
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 su
21.
by colinmcd 1y ago
It won't typecheck, which is good in this case, because as you say that's a very bad idea :)
22.
by colinmcd 1y ago
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&#x
23.
by colinmcd 1y ago
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&#
24.
by colinmcd 1y ago
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
25.
by colinmcd 1y ago
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/z
26.
by colinmcd 1y ago
This is not done for Zod's benefit. It's done for the benefit of libraries that depend on Zod, and the users of those libraries. If a library wants to add "incremental" support for Zod4 (that is, without dropping support
27.
by colinmcd 1y ago
Some kind of affordance for FormData/URLSearchParams-style structures is definitely in scope. It was a late cut. Ultimately HTML inputs/forms are an implicit type system unto itself—certainly HTML has a very different notion of &q
28.
by colinmcd 1y ago
Ecosystem libraries would need to switch from a single peer dependency on Zod to two optional peer dependencies. Despite "optional peer dependencies" technicall being a thing, its functionally impossible for a library to determine
29.
by colinmcd 1y ago
Author here, AMA! Regarding the versioning: I wrote a fairly detailed writeup here[0] for those who are interested in the reasons for this approach. Ultimately npm is not designed to handle the situation Zod finds itself in. Zod is subject
30.
by colinmcd 1y ago
These numbers don't reflect anything useful. This is the total size of the code in the package, most of which will be tree-shaken. In Zod's case, the package now contains three independent sub-libraries. I recommend plugging a scr

More ›