Українська

jpm

Швидкий, компактний і безпечний за замовчуванням менеджер пакетів для JavaScript

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

ПочатиGitHub

Кожен рядок написав Claude Code. Під керівництвом одного інженера. Перевірено тестами всіх інших.

  • ~2 MBодин бінарний файл, без середовища виконання
  • 1.22 sхолодне встановлення nuxt на GitHub CI
  • 34 MBпам’яті на встановлення nuxt у GitHub CI

Швидкість

Швидкий там, де CI витрачає час

Три реальні проєкти, чотири фази встановлення, вісім менеджерів пакетів, живий реєстр npm. На GitHub CI jpm найшвидший у 9 з 12 клітинок; інші три показано так, як їх виміряно.

Машина
Фаза
Проєкт

Ні кешу, ні lockfile, ні 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 найшвидший: 15× порівняно з npm.

Реальний час (wall time), медіани: ubuntu-latest з 4 ядрами (5 запусків) і Windows 11 з увімкненим Defender (3 запуски), 2026-09-30. Повні таблиці з процесорним часом: docs/benchmarks.md.

Почати

Перехід однією командою

Запустіть jpm install у своєму проєкті. jpm імпортує ваш поточний lockfile у власний jpm.lock з тими самими версіями.

  • package-lock.json і npm-shrinkwrap.json (npm 7+), pnpm-lock.yaml (pnpm 9+) та bun.lock переносяться як є: ті самі версії й те саме дерево, без запитів до реєстру.
  • yarn.lock з yarn 1 або yarn 2 і новіших зберігає всі версії, які вибрав yarn. jpm запитує в реєстру лише те, чого немає в yarn.lock: peer-залежності, платформи та bin-файли.
  • Ваш старий lockfile лишається недоторканим. Видаліть його, коли будете готові.
  • CI працює й під час переходу: jpm ci і jpm install --frozen-lockfile встановлюють зі старого lockfile як є, доки jpm.lock не закомічено.
  • jpm також читає workspaces, pnpm-workspace.yaml, каталоги, overrides, resolutions і патчі.

Старі формати, застарілі lockfile та все інше: 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
Кеш CI після холодного встановлення next
Кеш CI після холодного встановлення next
npm194 MB
yarn328 MB
jpm347 MB
pnpm433 MB
bun466 MB

Сховище

Кожен файл зберігається один раз. Кожен пакет збирається один раз.

jpm тримає одне сховище на машину й збирає каталог кожного пакета один раз для всіх проєктів, які його використовують. Повторне встановлення — це здебільшого створення посилань.

  1. Контентно-адресоване сховище

    Кожен tarball перевіряється за своїм integrity, а потім один раз розпаковується в ~/.jpm/store. Кожен файл зберігається один раз, за своїм хешем, лише для читання.

  2. Глобальне віртуальне сховище

    Кожен пакет збирається один раз як запис: name@version плюс короткий дайджест графа залежностей, якщо вони в нього є. Його файли — жорсткі посилання зі сховища, а залежності підключаються посиланнями поруч із ним, тож він може імпортувати лише те, що оголосив.

  3. Ваш node_modules

    node_modules проєкту посилається на ці записи. Тепле встановлення створює лише ці кілька посилань: 4 ms для nitro на GitHub CI.

  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: усередині проєкту

Turbopack у Next нічого не компілює поза проєктом, а 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-архівів або шляхи поза своїми межами. Звідки береться код, вирішують лише ваш проєкт і його workspaces.

  • Перевірено, перш ніж стане видимим

    Кожен пакет перевіряється за integrity з lockfile, перш ніж будь-який його файл стане видимим для вашого проєкту.

  • Жодних секретів у lockfile

    Облікові дані ніколи не потрапляють у jpm.lock: токени лишаються у вашому .npmrc, а git url із паролем відхиляється.

  • Склонований репозиторій не знизить планку

    Власний .npmrc проєкту не може вимкнути перевірки TLS, підмінити CA чи проксі або послабити вимогу до віку релізу. jpm ігнорує там такі налаштування й називає їх у попередженні.

  • Власний TLS, без OpenSSL

    jpm працює з TLS через власний код, протестований на Project Wycheproof і тестових векторах із RFC, і перевіряє сертифікати за кореневими сертифікатами Mozilla та вашої системи.

  • Середовища виконання перевіряються за підписом

    Середовище Node.js, яке запитує пакет, перевіряється за SHASUMS256.txt релізу, а цьому файлу довіряють лише тоді, коли його підпис збігається з ключами релізів Node.

  • Менша поверхня атаки

    Один бінарний файл ~2 MB, без середовища виконання й без власного дерева залежностей: менше коду між вами та реєстром.

Безпека за замовчуванням — це не пісочниця: схвалений вами скрипт виконується з вашими правами. Подробиці: docs/install-scripts.md і docs/configuration.md.

Історія

Написано Claude Code. Перевірено тестами всіх інших.

Усе почалося з випуску подкасту Syntax, де upm хвалили як швидший і менший за решту. Менший, бо працює на Node.js. Тож: а що, як портувати його на Rust і зробити справді малим? І що потрібно, щоб перетворити одноразову спробу ШІ на щось, чому можна довіряти в CI?

Claude Code на Claude Opus 5.5 написав кожен рядок, включно з власним TLS і криптографією. JT Turner, інженер із 27 роками досвіду, ухвалював рішення. Коли Claude заперечував проти власного TLS, умова була така: тестувати так, ніби ми йому не довіряємо. Тому кожне «працює» перевіряється чужими тестами: Wycheproof, RFC і тестовими наборами npm, pnpm, yarn і bun.

Вирішують цифри. HTTP/2-клієнт було написано, протестовано на раннерах GitHub і настільному комп'ютері, визнано повільнішим і ненажерливішим до CPU — і видалено.

Чи ідеальний jpm? Ні. Ідеального не буває. Буває достатньо добре, буває чудово, і буває протестовано достатньо, щоб знати, що з цього маєте ви.

JT Turner

Читати всю історію

Спробуйте jpm у своєму CI. А потім зробіть те, на що, як вам здавалося, не було часу.

Встановити jpm