AI 概述
Zod作者推出基于Node、Rust编写的一体化工具链Nub，不替代Node而是增强开发体验，整合脚本运行、npx、依赖安装、Node版本管理等工具，启动速度远超pnpm、npx，兼容各类锁文件可增量接入，默认强化供应链安全，与自研运行时Bun、Deno定位有明显区别。
目录
文章目录隐藏
就是前几天，前端工具链又杀出来一个狠角色。
这次不是 Bun，不是 Deno，也不是某个新的运行时，而是一个叫 Nub 的 Node.js 工具链。
它刚进入公测，作者是 colinhacks，也就是 Zod 的作者。
一句话概括：
Nub 想做一个更快、更现代、但不替代 Node 的 JavaScript 工具链。
这点很关键。
过去几年，很多新工具都想解决工具链的问题。
比如 Bun 想用一个全新的运行时，把包管理器、打包器、测试工具、运行时全部整合起来；
Deno 也想从安全、标准库、TypeScript 支持等方向重新设计 JavaScript 运行体验。
但 Nub 的思路不一样。
它不是重新造一个运行时，而是直接站在 Node 上。
也就是说：
Bun / Deno：我来替代 Node Nub：我来增强 Node
这也是 Nub 最有意思的地方。
官方给 Nub 的定位是：
一个 all-in-one Node.js toolkit。
它是一个 Rust 写的单文件工具链，可以替代你日常开发里一堆常用命令：
nub index.ts # 直接运行 TypeScript 文件 nub run dev # 运行 package.json scripts nubx prisma generate # 替代 npx / pnpm dlx nub install # 安装依赖 nub watch src/server.ts # 文件变化自动重启 nub node install 26 # 管理 Node 版本
如果你是前端开发，应该很熟悉这种体验。
平时一个 Node 项目里，经常会混着用：
node npm run pnpm run npx tsx ts-node dotenv nodemon nvm corepack
Nub 想干的事情就是：
把这些常用工具压成一个命令。
这也是它和传统包管理器最大的区别。
而 Nub 是想把这些东西放到一起。
这次 Nub 最容易出圈的点，就是速度。
官方给了几个非常夸张的数据。
第一个是 nub run。
它号称比 pnpm run 快 24 倍。
为什么？
因为 npm run、pnpm run 本身也是 Node 程序。
你每次执行一个 script，其实都要先启动一遍包管理器，加载配置、解析 workspace、处理脚本环境，然后才真正执行你的命令。
这中间会有几百毫秒的额外开销。
在小项目里，你可能只是觉得“怎么慢半拍”；但在 monorepo 里，如果几十个包都要跑脚本，这个开销会被放大很多次。
Nub 的做法是用 Rust 实现 script runner，尽量把这部分启动开销压下去。
官方 benchmark 里，nub run 的开销大概是 14ms，而 npm run 是 300ms+，pnpm run 甚至更高。
这意味着什么？
不是说你的构建会凭空快 24 倍。
而是说：
命令启动这一层，几乎变成瞬时响应。
比如你跑：
nub run dev nub run build nub run test
体感上会更接近“按下去立刻执行”。
第二个重点是 nubx。
它可以理解成一个更快的 npx。
平时我们经常会写：
npx eslint . npx prisma generate npx tsc --noEmit
问题是，npx 自己也有启动成本。即使你只是执行一个非常简单的本地 CLI，它也要先跑一套 Node 包管理器逻辑。
Nub 的 nubx 会优先从本地 node_modules/.bin 找命令，然后直接执行。官方给的数据是：
nubx：约 11ms npx：200ms+
这个方向其实很实用。
尤其是现在很多项目里，CLI 调用越来越多：
eslint prettier vite vitest tsc prisma drizzle storybook
这些命令单次慢一点无所谓，但每天高频执行，体验差异就出来了。
Nub 也内置了包管理能力，也就是：
nub install
这个部分最重要的不是“又多了一个包管理器”，而是它强调 兼容现有项目。
如果你项目现在用的是：
package-lock.json pnpm-lock.yaml bun.lock
Nub 会尝试读取并写回你当前已有的 lockfile，而不是强行生成一个新的 Nub 专属 lockfile。
这点很聪明。
因为今天前端团队最怕的不是工具不够快，而是迁移成本太高。
一旦你要求团队改 lockfile、改 CI、改所有脚本、改开发习惯，那再快也很难落地。
Nub 的切入点是：
你可以先不迁移包管理器 只把 nub run / nubx 用起来
也就是说，它可以增量采用。
这比“全家桶式替换”更现实。
最近 npm 生态的供应链安全问题越来越多，尤其是各种 postinstall 脚本攻击。
你装一个依赖，结果它安装阶段直接执行脚本，这件事本身就很危险。
Nub 在 install 上默认更保守：依赖的 lifecycle scripts 默认不执行，除非你明确批准。它还加入了新版本冷却时间、来源校验、非 registry 传递依赖阻止等机制。
简单来说，它不只是追求快，也在试图解决 Node 包管理器长期存在的安全问题。
这点和 npm v12 计划默认阻止危险生命周期脚本的方向很像。
前端包管理器正在进入一个新阶段：
以前大家只拼速度，现在开始拼安全默认值。
很多人第一反应可能是：
这不就是 Bun 吗？
不是。
Bun 是一个新的 JavaScript runtime。
Nub 底层还是 Node。
这就意味着，Nub 不需要重新实现一套 Node 兼容层，也不需要你赌一个新的生产运行时。你的代码最终还是跑在真实 Node 上。
Nub 更像是给 Node 套了一层现代开发体验：
TypeScript 直跑 .env 自动加载 watch 自动重启 npx 加速 npm run 加速 包管理加速 Node 版本管理
它的核心卖点不是“我比 Node 更像未来”，而是：
你继续用 Node，但体验别再这么原始。
这个定位其实很讨巧。
因为 Node 最大的问题从来不是生态不够强，而是日常开发体验太碎。
跑 TS 要 tsx，加载环境变量要 dotenv，自动重启要 nodemon，脚本执行靠 npm run，临时 CLI 靠 npx，Node 版本靠 nvm，包管理器还要在 npm、pnpm、yarn、bun 之间来回切。
Nub 就是冲着这堆碎片来的。
官方给的安装方式很简单：
npm install -g --ignore-scripts=false @nubjs/nub
然后就可以直接使用：
nub index.ts nub run dev nubx eslint . nub install
也可以把它加到 CI 里，用 nubjs/setup-nub 替代 actions/setup-node。
Nub 这个项目最值得关注的地方，不是“比 pnpm 快多少倍”，也不是“能不能干掉 npx”。
真正关键的是：
Node 工具链正在被重新整理。
以前我们习惯了一个项目塞十几个工具，每个工具解决一个小问题。但现在越来越多新工具都在往一个方向走：
一个二进制 一个入口 覆盖开发、安装、运行、调试、CI
Bun 是这样，Deno 是这样，现在 Nub 也来了。
区别在于，Nub 不想替代 Node。
它想把 Node 变得更好用。
如果这个方向跑通，未来前端项目里的很多命令，可能真的要变了。
以上关于Node Plus ？比 pnpm 快 24 倍！的文章就介绍到这了，更多相关内容请搜索码云笔记以前的文章或继续浏览下面的相关文章，希望大家以后多多支持码云笔记。
「点点赞赏，手留余香」
赞 14 赏
给作者打赏，鼓励TA抓紧创作！
微信
支付宝
还没有人赞赏，快来当第一个赞赏的人吧！
声明：本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权/违法违规/事实不符，请将相关资料发送至 admin@mybj123.com 进行投诉反馈，一经查实，立即处理！
重要：如软件存在付费、会员、充值等，均属软件开发者或所属公司行为，与本站无关，网友需自行判断
码云笔记 » Node Plus ？比 pnpm 快 24 倍！
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。