Русский

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