前 Zod 作者、前 Bun 团队成员 Colin McDonnell 推出全新开源项目，发布仅一天即登上 Hacker News 首页，收获近 2000 Star。

一个不打算「杀死」任何东西的野心项目

2026 年 6 月 24 日，一个名为 Nub 的开源项目正式发布 v0.2.0 版本。在 JavaScript 工具链已经极度拥挤的今天，这本该是一件稀松平常的事。但当它的作者是 Zod（TypeScript 生态最流行的校验库）的创造者 Colin McDonnell，而且此人此前还在 Bun 团队工作过时，事情就不一样了。

当天，Colin 在 Hacker News 上以「Show HN: Nub — A Bun-like all-in-one toolkit for Node.js」为题发布了帖子。截至发稿，该帖已获得 196 个点赞和 56 条讨论。GitHub 仓库在不到 48 小时内突破 1,800 Star，已有 970 次提交和 52 个版本发布——这一切对于一个刚进入公开 Beta 的项目来说，是一个相当炸裂的开局。

但最让人意外的，不是它的性能有多快，而是它主动放弃了什么：Nub 没有自己的运行时，没有自己的全局对象，没有 nub: 前缀的内置模块，没有 @nub/* 的 npm 作用域，甚至没有自己的 lockfile 格式。 它所做的一切，都在标准的 Node.js 之上运行。用 Colin 的话说：「把 Nub 明天删掉，你的代码照样能跑。」

问题的根源：Node.js 的生态碎片化

要理解 Nub 的价值，首先需要直面一个 Node.js 开发者每天都在经历的痛苦：工具碎片化。

运行 TypeScript？你需要 tsx 或 ts-node。管理依赖？npm、pnpm、yarn、bun 四选一。执行 CLI 工具？npx 或 pnpm dlx。切换 Node 版本？nvm、fnm、volta 任君挑选。加载环境变量？装个 dotenv-cli。监听文件变化？再装个 nodemon。每一个工具都有自己的配置文件、自己的命令行参数、自己的怪癖和边界情况。

Bun 和 Deno 试图用「另起炉灶」的方式解决这个问题——创建全新的运行时，把所有功能打包进去。但正如 Nub 官方博客所指出的，两者都未能动摇 Node.js 在生产环境中的统治地位。没有哪家主流云厂商将 Bun 或 Deno 视为一等公民部署目标，它们的 Node 兼容性也远远落后于真正的 Node（Bun 在 Deno 的兼容性测试中仅通过 40.5%）。

Nub 的核心论点很简洁：「Bun 和 Deno 在尝试替代 Node.js，而 Node.js 是不可替代的。我们要做的是增强它。」

一把瑞士军刀，但刀柄是 Rust 打造的

Nub 本质上是一个用 Rust 编写的单一二进制文件，将六个核心开发工具整合到一个 nub 命令中：

技术实现上，Nub 使用 oxc 作为 TypeScript/JSX 转译器，将其编译为 Node 原生插件（N-API），在内存中完成转译后直接交由标准 node 二进制执行。它利用 Node.js 2025 年引入的 module.registerHooks() 同步 API 来注入模块解析逻辑，开销仅为约 0.5 毫秒——Colin 在 HN 评论中特别提到，这个 API 是 Nub 的「关键解锁点」，此前的异步 API 会带来 19 毫秒的固定注册开销。

包管理器底层则嵌入了 aube 引擎——由知名开发者工具 mise 的作者 jdx 开发，兼容 pnpm 的 workspace 文件、hooks 和 pnpm-workspace.yaml，并且能双向识别已有的 pnpm-lock.yaml、package-lock.json 和 bun.lock。

性能：快到离谱，但要看清比的是什么

Nub 官方公布了一系列基准测试数据，数字相当抢眼：

这些数据令人印象深刻，但需要理性看待。Nub 是一个 Rust 原生二进制文件，而 npm/pnpm 是 Node.js 应用，冷启动开销天然不同。脚本分发和 CLI 执行的「30 倍」差距主要来自进程启动开销，在实际长时间运行的应用中差距会大幅缩小。不过，在开发循环中——频繁的 run、exec、文件执行——这些毫秒级的积累确实能带来可感知的体验提升。

在 Node 兼容性方面，Nub 的成绩更为实在：在 Deno 的跨运行时兼容性测试集中，Nub 通过了 98.8%（4315/4368），与原生 Node 几乎持平，而 Deno 为 77.4%，Bun 仅为 40.5%。

安全：默认拒绝构建脚本

Nub 在安全方面的设计值得关注。它默认拒绝所有 postinstall 脚本，仅对已知的原生包（如 esbuild、sharp 等）放行。每次解析依赖时，它会查询 OSV（开源漏洞）数据库检测恶意包，并拒绝「信任降级」——即如果某个版本失去了 provenance 签名认证，Nub 会直接拒绝安装。此外，它还设置了 24 小时的最低发布年龄门槛，防止供应链攻击中常见的「发布即利用」模式。

在 paranoid: true 模式下，构建脚本将在完全无网络的沙箱中执行，将供应链风险压到最低。

社区反响：赞赏与质疑并存

Hacker News 的讨论呈现出典型的「谨慎乐观」基调。

最受欢迎的正面反馈来自一位名为 ssalbdivad 的用户（ArkType 作者），他报告说「刚刚完成了一个将整个 monorepo 迁移到 nub 的 PR，零问题，速度快得离谱」。多位评论者赞赏了 Nub 「增强而非替代」的哲学——「尊重既有技术，而不是重写一个更差的版本」，这被视为与 Bun/Deno 截然不同的成熟路线。

质疑声主要集中在三个方面。其一，AI 生成代码的品质——有人指出 Claude（AI）是该仓库的第二大贡献者，引发了对代码质量的担忧。对此有评论者反驳道：「在 vibe-coded 的运行时上跑你的应用，和只用 AI 写本地开发工具，是完全不同的事。」其二，生产就绪度——目前 Nub 的 nub build 命令尚未发布（官方承诺「即将推出」），后端生产部署仍建议直接使用标准 Node。其三，攻击面——内置的 .env 加载等功能虽然方便，但也意味着更多的代码路径需要审计。

零锁定：一个大胆的承诺

Nub 最具争议也最具吸引力的设计决策，是它对「零锁定」的极端坚持。项目不存在任何 Nub 专有 API——没有全局对象，没有私有模块命名空间，没有自创的配置格式。它提供的所有增强功能都是 Web 标准、TC39 提案、未加 flag 的 Node 特性，或者已有生态工具的兼容层（如 YAML/TOML 导入、.env 加载）。

这意味着，当你选择 Nub 时，你并没有「选择」一个平台——你只是在选择一种更舒适的 Node.js 开发方式。如果明天 Nub 消失了，你只需要把 nub run 换回 npm run，代码无需任何修改。

这种设计哲学与 JavaScript 生态一贯的「锁定焦虑」形成了鲜明对比。在经历了从 Grunt 到 Gulp、从 Webpack 到 Vite 的无数次迁移之后，开发者对工具链的信任已经十分脆弱。Nub 选择用「可以随时离开」来换取「愿意留下」。

写在最后

Nub 目前仍是 v0.2.0 的早期版本，前路漫长。nub build（生产打包）、nub compile（单文件二进制输出）、官方 Docker 镜像等关键功能仍在路线图上。1,800 Star 的热度能否转化为长期的社区维护力，也有待观察——毕竟 Colin 一个人的精力有限，而这个项目同时在挑战 npm、npx、tsx、nvm 和 nodemon 的领地。

但有一点是确定的：Nub 代表了一种在 JavaScript 工具链战争中被长期忽视的路线——不是推翻重建，而是在巨人的肩膀上做减法。对于那些受够了工具碎片化、但又不想背弃 Node.js 庞大生态的开发者来说，Nub 提供了一个值得认真考虑的选项。

项目地址：github.com/nubjs/nub | 官网：nubjs.com | 许可证：MIT