简体中文

jpm

快速、小巧、默认安全的 JavaScript 包管理器

curl -fsSL https://getjpm.sh | sh

快速上手GitHub

每一行代码都由 Claude Code 编写。由一位工程师主导。用其他所有项目的测试来检验。

  • ~2 MB单个二进制文件，无需安装运行时
  • 1.22 s在 GitHub CI 上冷安装 nuxt
  • 34 MB在 GitHub CI 上安装 nuxt 所用的内存

速度

快在 CI 最耗时的地方

三个真实项目、四个安装阶段、八个包管理器，直接对接线上 npm registry。在 GitHub CI 上，jpm 在 12 项中的 9 项最快；另外三项按实测结果如实展示。

机器
阶段
项目

无缓存、无锁文件、无 node_modules。

安装墙钟时间，越短越快GitHub CI，Linux · nuxt · 591 个包
GitHub CI，Linux, 冷, nuxt · 591 个包
包管理器墙钟时间
jpm1.22 s
bun 1.4.21.28 s
pnpm 12.8.11.72 s
aube 2.6.03.00 s
upm 1.3.13.52 s
deno 2.9.67.64 s
yarn 4.18.19.63 s
npm 12.1.018.54 s

jpm 在此最快，比 npm 快 15×。

墙钟时间，取中位数：4 核 ubuntu-latest（5 次运行）和开启 Defender 的 Windows 11（3 次运行），2026-09-30。含 CPU 时间的完整表格见 docs/benchmarks.md。

快速上手

一条命令完成切换

在项目中运行 jpm install。jpm 会把你现有的锁文件导入到它自己的 jpm.lock 中，版本保持不变。

  • package-lock.json 和 npm-shrinkwrap.json（npm 7+）、pnpm-lock.yaml（pnpm 9+）以及 bun.lock 会原样迁移：版本相同，依赖树相同，无需查询 registry。
  • yarn.lock 无论来自 yarn 1 还是 yarn 2 及更高版本，yarn 选定的每个版本都会保留。jpm 只向 registry 查询 yarn.lock 没有记录的信息：peer 依赖、平台和 bin。
  • 旧的锁文件不会被改动，准备好后再删除即可。
  • 切换期间 CI 照常运行：在提交 jpm.lock 之前，jpm ci 和 jpm install --frozen-lockfile 会按旧锁文件原样安装。
  • 它还会读取工作区、pnpm-workspace.yaml、catalog、覆盖（overrides 和 resolutions）以及补丁。

旧格式、过期的锁文件及其他情况：docs/migrating.md。

$ cd your-project
$ jpm install   # 读取 package-lock.json / pnpm-lock.yaml / yarn.lock / bun.lock → 写入 jpm.lock

轻量

小到让你忘了它的存在

一个二进制文件，背后别无他物；安装时内存占用很少；存储中每个文件只保留一份。

并非每项数据都对 jpm 有利：npm 和 yarn 保存的是压缩的 tarball，所以缓存更小。jpm 保存解压后的文件，随时可以链接。

GitHub CI，Linux，2026-09-30。二进制大小取自 README 中的约数。

二进制大小（约）
二进制大小（约）
jpm~2 MB
pnpm~60 MB
bun~80 MB
aube~150 MB
峰值内存，nuxt ci 安装
峰值内存，nuxt ci 安装
jpm34 MB
bun89 MB
pnpm184 MB
npm387 MB
冷安装 nuxt 后的磁盘占用（node_modules 与存储）
冷安装 nuxt 后的磁盘占用（node_modules 与存储）
jpm244 MB
bun261 MB
pnpm290 MB
npm443 MB
冷安装 next 后的 CI 缓存
冷安装 next 后的 CI 缓存
npm194 MB
yarn328 MB
jpm347 MB
pnpm433 MB
bun466 MB

存储

每个文件只存一次。每个包只构建一次。

jpm 每台机器只用一个存储，每个包的目录只构建一次，供所有用到它的项目共享。再次安装基本上只是创建链接。

  1. 内容寻址存储

    每个 tarball 先校验完整性，再一次性解压到 ~/.jpm/store。每个文件按哈希只保存一份，且为只读。

  2. 全局虚拟存储

    每个包只构建一次，成为一个条目：name@version，有依赖时再附上其依赖图的简短摘要。它的文件从存储硬链接而来，依赖则链接在它旁边，因此它只能导入自己声明过的内容。

  3. 你的 node_modules

    项目的 node_modules 链接到这些条目。热安装只需创建这几个链接：在 GitHub CI 上，nitro 只需 4 ms。

  4. 其他所有项目

    同一台机器上的下一个项目链接到相同的条目。没有变化时，重复安装只需检查几个链接，1–2 ms 即可完成。

~/.jpm/store文件，按哈希3fa19c07e4b271d80b5ec6a3硬链接~/.jpm/store/v1/links条目，只构建一次[email protected]node_modules/debugnode_modules/ms[email protected]node_modules/msapp-one/app-two/node_modules/debugnode_modules/debug链接

Next.js 和 Nuxt：放在项目内部

Next 的 Turbopack 不会编译项目之外的任何内容，而 Nuxt 会导入它未声明的包。对于依赖 next 或 nuxt 的项目，jpm 改为在 node_modules/.jpm 中构建条目，仍然从存储硬链接。

node_modules/next -> .jpm/[email protected]…/node_modules/next
node_modules/.jpm/[email protected]…/node_modules/next/
node_modules/.jpm/[email protected]/node_modules/react/

完整说明：docs/how-it-works.md。

安全

默认安全

安全的设置无需你开口，开箱即是。要放宽哪一项，由你在自己的配置中决定，而不是由某个包或某个克隆来的仓库决定。

  • 安装脚本等你批准

    依赖的安装脚本是大多数 npm 恶意软件的运行途径，在你对该包及版本执行 jpm approve 之前不会运行。新版本需要重新批准。

  • 新版本先等一天

    最近一天内发布的版本不会被选用（min-release-age），即使依赖树深处的某个包精确锁定了它也一样，因此被劫持的发布无法借精确版本号混进来。

  • 没有意外的来源

    已发布的包不能引入 git 或 tarball 依赖，也不能引用自身之外的路径。只有你的项目及其工作区能决定代码从哪里来。

  • 可见之前先校验

    每个包在其任何文件对你的项目可见之前，都会先按锁文件中的完整性值进行校验。

  • 锁文件中没有机密

    凭据绝不会写入 jpm.lock：令牌留在你的 .npmrc 中，带密码的 git url 会被拒绝。

  • 克隆的仓库无法降低门槛

    项目自带的 .npmrc 无法关闭 TLS 检查、替换 CA 或代理，也无法放宽发布时长限制。jpm 会忽略其中的这些设置，并在警告中列出它们。

  • 自研 TLS，不用 OpenSSL

    jpm 用自己的代码实现 TLS，经过 Project Wycheproof 和各 RFC 测试向量的检验，并依据 Mozilla 的根证书和你系统的根证书校验证书。

  • 运行时经签名校验

    包所要求的 Node.js 运行时会与该版本的 SHASUMS256.txt 核对，只有在其签名与 Node 的发布密钥匹配后才会被信任。

  • 更小的攻击面

    一个 ~2 MB 的二进制文件，没有需要安装的运行时，也没有自己的依赖树：你与 registry 之间的代码更少。

默认安全不等于沙箱：你批准的脚本会以你的身份运行。详情见 docs/install-scripts.md 和 docs/configuration.md。

背后的故事

由 Claude Code 编写。用其他所有项目的测试来检验。

一切始于一期 Syntax 播客，节目里称 upm 比其他工具更快、更小。说它小，是因为它跑在 Node.js 上。那么：如果把它移植到 Rust，做到真正的小，会怎样？要把 AI 一次生成的成果变成你敢放进 CI 的东西，又需要什么？

运行 Claude Opus 5.5 的 Claude Code 编写了每一行代码，连它自己的 TLS 和加密实现也不例外。拥有 27 年经验的工程师 JT Turner 负责拍板。当 Claude 对自研 TLS 提出异议时，条件是：就当我们不信任它那样去测试。所以每一句“能用了”都要用别人的测试来检验：Wycheproof、各 RFC，以及 npm、pnpm、yarn 和 bun 的测试套件。

由数据说了算。我们曾构建了一个 HTTP/2 客户端，在 GitHub 的 runner 和一台台式机上做了基准测试，发现它更慢、更耗 CPU，于是删掉了。

jpm 完美吗？不。完美并不存在。有够用，有出色，还有测试得足够充分、让你知道自己手里是哪一种。

JT Turner

阅读完整故事

在你的 CI 中试试 jpm。然后去做那件你以为没时间做的事。

安装 jpm