jpm

作者认为即使经过大量测试，也不能证明代码没有 bug，计划在自己所有项目中继续使用 jpm，并要求修复 PR（包括 AI 提交的）必须用测试证明在修复什么。

jpm 二进制被压到 2MB，在 GitHub Actions runner 上冷启动安装 nuxt（591 个包）的中位数：jpm 1.22 秒，bun 1.28 秒，pnpm 1.72 秒，npm 18.54 秒。

jpm 的安全特性包括：不审批就不运行脚本、包发布时间不足一天不升级到最新版、围绕 .npmrc 的安全加固。

jpm 是一个能在 npm、pnpm、yarn 和 bun 项目中工作的 JavaScript 包管理器，由作者用 Rust 构建。

Claude 曾反对为 jpm 实现 HTTP/2，但作者坚持；实测显示 HTTP/2 在家用连接上快约 17%，但在 GitHub runner 上持平或更差，冷启动 nuxt 安装最慢可达 2 倍，大 tarball 上多消耗 8% 到 15% CPU，并增加 60KB 二进制体积，最终 3671 行 HTTP/2 代码被删除。

作者坚持不自动运行依赖的 install 脚本，除非明确列出，理由是审批前可让 AI 审查脚本是否存在问题。

jpm 默认开启 Node 签名检查，因为 Claude 测出该检查仅需 15 到 19 毫秒，认为“开关意味着没人会打开它”。

jpm 将全局存储作为默认行为，因为作者认为如果 99% 的包都能用，就不应该设为可选。

在验证过程中，node-semver 自己的测试发现 jpm 有 25 处判断不一致，例如把 ^9007199254740991.0.0 当作合法范围。

jpm 在 npm-package-arg 的测试中最初 154 个只通过 117 个。

一次安全扫描发现克隆仓库的 .npmrc 能把 registry token 通过它自己的代理发出去，概念验证捕获到了 Bearer USER-SECRET-TOKEN。

在真实仓库上，jpm 与 pnpm 的依赖链接差异从 1320 降到 183，与 npm 的差异从 614 降到 14。

jpm 的初版由 Claude 在一个下午内生成，依赖大量第三方 Rust crate；当晚作者又让它生成了自定义的 HTTP、JSON、crypto 和 TLS 模块以缩小体积。

作者用五天时间让 Claude 对 166 个大型公开项目进行安装和构建测试，并与项目原本使用的包管理器对比，最终合并了 261 个 PR。

Claude 曾反对作者自实现 TLS 和 crypto，称其为“永远不该自己写的代码”，但作者坚持，Claude 随后列出 Wycheproof、NIST vectors、x509-limbo、BoGo 等测试套件，并通过了这些测试。