jpm
A JavaScript package manager written in Rust that operates within npm, pnpm, yarn and bun projects. Its code was generated by an AI (Claude) under the guidance and verification of human engineers. It includes custom built-in HTTP, JSON, crypto and TLS modules in order to reduce its size.
Timeline (last 90 days)
jpm is a JavaScript package manager that works in npm, pnpm, yarn and bun projects, built by the author in Rust.
The first version of jpm was generated by Claude in a single afternoon and relied on a large number of third-party Rust crates; that evening the author had it generate custom HTTP, JSON, crypto and TLS modules to shrink the size.
The author spent five days having Claude run install and build tests on 166 large public projects, comparing against the package managers the projects originally used, and ultimately merged 261 PRs.
Claude once objected to the author implementing TLS and crypto himself, calling it "code you should never write yourself," but the author insisted, and Claude then listed test suites such as Wycheproof, NIST vectors, x509-limbo and BoGo, all of which were passed.
Claude once objected to implementing HTTP/2 for jpm, but the author insisted; measurements showed HTTP/2 was about 17% faster on home connections, but flat or worse on GitHub runners, with cold-start nuxt installs up to 2 times slower, 8% to 15% more CPU consumed on large tarballs, and a 60KB increase in binary size, so the 3671 lines of HTTP/2 code were ultimately deleted.
The author insists on not automatically running dependencies' install scripts unless they are explicitly listed, on the grounds that before approval AI can be used to review whether the scripts have problems.
jpm enables Node signature checking by default, because Claude measured that the check takes only 15 to 19 milliseconds and held that "an option means nobody will turn it on."
jpm makes global storage the default behavior, because the author believes that if 99% of packages work with it, it should not be made optional.
During validation, node-semver's own tests found 25 inconsistent judgments in jpm, for example treating ^9007199254740991.0.0 as a valid range.
In npm-package-arg's tests, jpm initially passed only 117 of 154.
5 more timeline events
All Facts (15)
The author believes that even after extensive testing, it cannot be proven that the code has no bugs, plans to continue using jpm in all of his own projects, and requires that fix PRs (including those submitted by AI) must use tests to prove what they are fixing.
50%UnverifiedThe jpm binary was compressed to 2MB, and the median cold-start install of nuxt (591 packages) on a GitHub Actions runner: jpm 1.22 seconds, bun 1.28 seconds, pnpm 1.72 seconds, npm 18.54 seconds.
50%Unverifiedjpm's security features include: not running scripts without approval, not upgrading to the latest version when a package was released less than a day ago, and security hardening around .npmrc.
50%Unverifiedjpm is a JavaScript package manager that works in npm, pnpm, yarn and bun projects, built by the author in Rust.
50%UnverifiedClaude once objected to implementing HTTP/2 for jpm, but the author insisted; measurements showed HTTP/2 was about 17% faster on home connections, but flat or worse on GitHub runners, with cold-start nuxt installs up to 2 times slower, 8% to 15% more CPU consumed on large tarballs, and a 60KB increase in binary size, so the 3671 lines of HTTP/2 code were ultimately deleted.
50%UnverifiedThe author insists on not automatically running dependencies' install scripts unless they are explicitly listed, on the grounds that before approval AI can be used to review whether the scripts have problems.
50%Unverifiedjpm enables Node signature checking by default, because Claude measured that the check takes only 15 to 19 milliseconds and held that "an option means nobody will turn it on."
50%Unverifiedjpm makes global storage the default behavior, because the author believes that if 99% of packages work with it, it should not be made optional.
50%UnverifiedDuring validation, node-semver's own tests found 25 inconsistent judgments in jpm, for example treating ^9007199254740991.0.0 as a valid range.
50%UnverifiedIn npm-package-arg's tests, jpm initially passed only 117 of 154.
50%UnverifiedA security scan found that a cloned repository's .npmrc could send the registry token out through its own proxy, and the proof of concept captured the Bearer USER-SECRET-TOKEN.
50%UnverifiedOn real repositories, jpm's dependency-linking differences from pnpm dropped from 1320 to 183, and its differences from npm dropped from 614 to 14.
50%UnverifiedThe first version of jpm was generated by Claude in a single afternoon and relied on a large number of third-party Rust crates; that evening the author had it generate custom HTTP, JSON, crypto and TLS modules to shrink the size.
50%UnverifiedThe author spent five days having Claude run install and build tests on 166 large public projects, comparing against the package managers the projects originally used, and ultimately merged 261 PRs.
50%UnverifiedClaude once objected to the author implementing TLS and crypto himself, calling it "code you should never write yourself," but the author insisted, and Claude then listed test suites such as Wycheproof, NIST vectors, x509-limbo and BoGo, all of which were passed.
50%