pnpm vs npm vs Yarn 2026: сравнение и выбор

Выбор пакетного менеджера для JavaScript-проекта может показаться тривиальным решением — до тех пор, пока вы не столкнётесь с CI-пайплайном, который ставит зависимости 12 минут, или не обнаружите, что node_modules занимает 3 ГБ на ноутбуке. В 2026 году экосистема пакетных менеджеров сформировалась вокруг трёх основных игроков: npm, Yarn и pnpm. Каждый из них прошёл долгий путь эволюции и предлагает принципиально разные подходы к управлению зависимостями.

Эта статья — практическое сравнение npm 11, Yarn 4 (Berry) и pnpm 10 по ключевым параметрам: архитектура хранения пакетов, скорость установки, потребление дискового пространства, безопасность, поддержка монорепозиториев и опыт разработчика. Она адресована фронтенд- и бэкенд-разработчикам, тимлидам и DevOps-инженерам, которые выбирают инструментарий для нового проекта или оценивают целесообразность миграции.

Краткий обзор участников

npm — стандарт по умолчанию

npm (Node Package Manager) появился вместе с Node.js в 2010 году и остаётся пакетным менеджером, который устанавливается автоматически с каждой копией Node.js. Текущая стабильная версия — npm 11.7.0 (декабрь 2025). Реестр npmjs.com содержит более 2,5 миллионов пакетов — это крупнейшая экосистема пакетов для любого языка программирования.

Философия npm — совместимость и универсальность. Плоская структура node_modules с алгоритмом hoisting позволяет подавляющему большинству пакетов работать без дополнительной настройки. С версии 7 npm поддерживает workspaces, а с версии 8 — npm audit signatures для верификации подписей пакетов. На GitHub репозиторий npm/cli набрал около 9 400 звёзд, а еженедельные загрузки самого пакета npm через npmjs.com превышают 99 миллиардов (эта цифра включает автоматические установки через Node.js).

Основные команды привычны каждому JavaScript-разработчику:

npm install              # установка всех зависимостей
npm install express      # добавление пакета
npm run build            # запуск скрипта
npm audit                # проверка уязвимостей
npm ci                   # чистая установка для CI (из lock-файла)

Yarn — пионер улучшений

Yarn был создан в 2016 году инженерами Facebook (ныне Meta), Google и Exponent как ответ на проблемы npm того времени: отсутствие lock-файла, непредсказуемость установок и низкую скорость. Yarn 1 (Classic) ввёл yarn.lock, параллельную загрузку пакетов и офлайн-кеш.

В 2020 году проект совершил радикальный переход на архитектуру Berry (Yarn 2+), а в 2023 году вышел Yarn 4 — текущая мажорная ветка. Актуальная версия — Yarn 4.9.4. На GitHub репозиторий yarnpkg/berry собрал около 41 500 звёзд.

Главная инновация Yarn Berry — режим Plug’n’Play (PnP), который полностью отказывается от директории node_modules. Вместо этого зависимости хранятся в виде сжатых zip-файлов, а разрешение модулей происходит через специальный .pnp.cjs загрузчик. Это позволяет реализовать стратегию Zero Installs: lock-файл и кеш зависимостей коммитятся в репозиторий, и после клонирования проект сразу готов к запуску.

yarn install             # установка зависимостей
yarn add express         # добавление пакета
yarn run build           # запуск скрипта
yarn dlx create-next-app # аналог npx
yarn workspaces foreach run build  # команда по всем воркспейсам

pnpm — эффективность через ссылки

pnpm (performant npm) был создан Золтаном Кочаном (Zoltan Kochan) в 2017 году с единственной целью — решить проблему дублирования пакетов на диске. К 2026 году pnpm превратился в зрелый инструмент с мощной поддержкой монорепозиториев и фокусом на безопасности. Текущая версия — pnpm 10.30.1. На GitHub — около 33 500 звёзд, еженедельные загрузки на npmjs.com — около 40 миллионов.

Ключевая идея pnpm — content-addressable storage (хранилище с адресацией по содержимому). Все версии всех пакетов хранятся в одном глобальном хранилище (~/.pnpm-store). Когда проект запрашивает пакет, pnpm создаёт жёсткую ссылку (hard link) из глобального хранилища в директорию node_modules/.pnpm, а затем строит дерево символических ссылок (symlinks) для реальной структуры зависимостей. Это означает, что если 10 проектов на вашей машине используют lodash@4.17.21, файлы этого пакета хранятся на диске ровно один раз.

pnpm install             # установка зависимостей
pnpm add express         # добавление пакета
pnpm run build           # запуск скрипта
pnpm dlx create-next-app # аналог npx
pnpm -r build            # рекурсивная сборка по всем пакетам монорепо

Архитектура хранения пакетов

Фундаментальное различие между тремя менеджерами кроется в том, как именно они размещают пакеты на файловой системе. Это влияет на всё остальное: скорость, потребление диска, безопасность и совместимость.

npm: плоский hoisting

npm использует алгоритм hoisting (поднятия) — все зависимости, включая транзитивные, «вытягиваются» на верхний уровень node_modules. Это приводит к двум известным проблемам:

Phantom dependencies (фантомные зависимости) — ваш код может импортировать пакет, который не указан в package.json, просто потому что он был поднят из транзитивных зависимостей. Если при следующем обновлении этот пакет исчезнет из дерева — ваш код сломается.
Doppelgangers (двойники) — когда разные версии одного пакета нужны разным зависимостям, npm может создать несколько копий в разных вложенных node_modules, увеличивая размер.

Yarn PnP: без node_modules

Yarn Berry в режиме PnP вообще не создаёт node_modules. Пакеты хранятся в виде .zip-архивов в директории .yarn/cache, а файл .pnp.cjs содержит карту разрешения модулей. Node.js при запуске получает эту карту через флаг --require и разрешает импорты на лету.

Преимущество — скорость чтения (один файл вместо тысяч), полный контроль над тем, какие пакеты доступны для импорта (нет фантомных зависимостей), и возможность Zero Installs. Недостаток — не все инструменты корректно работают без node_modules. Для совместимости Yarn предоставляет режим nodeLinker: node-modules, который эмулирует привычную структуру.

pnpm: symlinks + hard links

pnpm использует гибридный подход. Внутри node_modules/.pnpm каждая зависимость размещена в плоском формате <name>@<version>/node_modules/<name>, а файлы — это жёсткие ссылки на глобальное хранилище. На верхнем уровне node_modules лежат только символические ссылки на прямые зависимости проекта. Это решает проблему фантомных зависимостей — транзитивные пакеты недоступны для импорта из корня проекта — и при этом не требует специального загрузчика, как Yarn PnP.

node_modules/
  .pnpm/
    express@4.21.0/
      node_modules/
        express/  -> hard link на ~/.pnpm-store
        body-parser/ -> symlink на .pnpm/body-parser@1.20.3/...
    body-parser@1.20.3/
      node_modules/
        body-parser/ -> hard link на ~/.pnpm-store
  express/ -> symlink на .pnpm/express@4.21.0/node_modules/express

Производительность: бенчмарки 2026

Скорость установки зависимостей — один из главных факторов, особенно в контексте CI/CD, где каждый пайплайн начинается с npm ci или pnpm install --frozen-lockfile.

Ниже приведены данные бенчмарков для проекта на базе React + TypeScript стартера (~400 зависимостей) и Next.js 15 приложения (~1200 зависимостей), по данным pnpm.io/benchmarks и независимых тестов dev.to.

Холодная установка (без кеша)

Менеджер	React-стартер (~400 deps)	Next.js 15 (~1200 deps)	Относительно npm
npm 11	14.3 сек	46.1 сек	1x (базовый)
Yarn 4 (PnP)	6.8 сек	18.2 сек	2.1–2.5x быстрее
pnpm 10	4.2 сек	12.4 сек	3.4–3.7x быстрее

Тёплая установка (с кешем, без lock-файла)

При наличии глобального кеша разница сокращается, но pnpm по-прежнему лидирует за счёт жёстких ссылок — ему не нужно копировать или распаковывать файлы, только создать ссылки.

Потребление дискового пространства

pnpm экономит до 70–80% дискового пространства при работе с несколькими проектами на одной машине. Если у вас 5 проектов, использующих React 19, Next.js 15 и TypeScript 5, npm создаст 5 полных копий всех зависимостей. pnpm — одну физическую копию и 5 наборов ссылок. Yarn PnP экономит место через zip-компрессию, но не делит пакеты между проектами.

На практике для крупного монорепозитория с 10–15 пакетами экономия pnpm может составлять от 5 до 15 ГБ по сравнению с npm.

Безопасность: уроки 2025 года

2025 год стал переломным для безопасности npm-экосистемы. Серия атак на цепочку поставок заставила все три менеджера усилить защитные механизмы.

Атаки на npm-экосистему в 2025

В сентябре 2025 года злоумышленники скомпрометировали 18 популярных npm-пакетов (включая chalk, debug, ansi-styles) через фишинговую кампанию, внедрив код для перехвата криптовалютных транзакций. Эти пакеты имели суммарно 2.6 миллиарда еженедельных загрузок.

В ноябре 2025 года произошла ещё более масштабная атака — самореплицирующийся червь Shai-Hulud, который скомпрометировал 796 пакетов с суммарными 132 миллионами ежемесячных загрузок. Червь использовал preinstall-скрипты для кражи учётных данных и установки бэкдоров.

Ответные меры

npm 11: В декабре 2025 года npm аннулировал все классические токены и перешёл на сессионные токены с двухфакторной аутентификацией для публикации. Также внедрена технология OIDC Trusted Publishing для CI-систем — короткоживущие токены вместо хранения секретов.

pnpm 10: Главное нововведение 2025 года — Security by Default. Начиная с версии 10, pnpm по умолчанию не выполняет preinstall и postinstall скрипты. Для пакетов, которым скрипты необходимы (например, esbuild, sharp), нужно явно разрешить их через параметр allowBuilds в .npmrc. Также pnpm ввёл параметр minimumReleaseAge — блокировку «свежих» публикаций (например, младше 24 часов), чтобы у сообщества было время обнаружить вредоносные обновления.

Yarn 4: Yarn реализовал Hardened Mode — валидацию разрешений в lock-файле и проверку соответствия метаданных пакетов с данными реестра. При обнаружении расхождений установка прерывается.

Строгость модели зависимостей

Важный аспект безопасности — модель изоляции зависимостей. npm с плоским hoisting позволяет импортировать любой транзитивный пакет, что создаёт неявные связи и расширяет поверхность атаки. pnpm и Yarn PnP обеспечивают строгий режим: доступны только те пакеты, которые явно объявлены в package.json. Это автоматически блокирует целые классы атак через фантомные зависимости.

Поддержка монорепозиториев

Монорепозиторий — хранение нескольких связанных пакетов или приложений в одном Git-репозитории — стал стандартной практикой для средних и крупных команд. Каждый из трёх менеджеров предлагает механизм workspaces, но с разным уровнем зрелости.

npm workspaces

npm поддерживает workspaces с версии 7. Конфигурация задаётся в корневом package.json:

{
  "name": "my-monorepo",
  "workspaces": [
    "packages/*",
    "apps/*"
  ]
}

Для запуска команды в конкретном воркспейсе используется флаг -w:

npm install lodash -w packages/utils
npm run build -w apps/web
npm run test --workspaces     # во всех воркспейсах

Основной недостаток: отсутствие нативной фильтрации, параллельного выполнения и понимания графа зависимостей между воркспейсами. Для серьёзной работы с монорепо npm обычно дополняют инструментами вроде Turborepo или Nx.

Yarn workspaces

Yarn первым ввёл концепцию workspaces и на сегодня предлагает один из самых зрелых инструментариев. Yarn 4 предоставляет команду yarn workspaces foreach с фильтрами, топологической сортировкой и параллельным выполнением:

yarn workspaces foreach -A run build           # все воркспейсы
yarn workspaces foreach -R --from app run build # app и его зависимости

Уникальная функция Yarn 4 — Constraints — система правил для монорепо, переработанная с Prolog на JavaScript-движок. Constraints позволяют гарантировать единообразие версий зависимостей, наличие обязательных полей в package.json и другие политики:

// yarn.config.cjs
module.exports = defineConfig({
  constraints: async (ctx) => {
    for (const workspace of ctx.workspaces()) {
      // Все воркспейсы должны использовать одну версию TypeScript
      workspace.set('devDependencies.typescript', '^5.7.0');
    }
  }
});

pnpm workspaces

pnpm предлагает, пожалуй, самый мощный набор инструментов для монорепо. Конфигурация задаётся в файле pnpm-workspace.yaml:

packages:
  - 'packages/*'
  - 'apps/*'
  - '!**/test/**'

Фильтрация — сильнейшая сторона pnpm. Мощный синтаксис --filter позволяет адресовать пакеты по имени, директории, зависимостям и даже по git-diff:

pnpm --filter @myorg/web build           # конкретный пакет
pnpm --filter @myorg/web... build         # пакет и все его зависимости
pnpm --filter ...@myorg/web build         # пакет и все зависящие от него
pnpm --filter "...[origin/main]" build    # только изменённые пакеты
pnpm -r --parallel build                  # все пакеты параллельно

В 2025 году pnpm ввёл Config Dependencies — возможность централизованно управлять хуками, патчами и разрешениями сборки для всех пакетов монорепо. Также pnpm из коробки поддерживает протокол workspace:* для внутренних зависимостей, который при публикации автоматически заменяется на реальную версию:

{
  "dependencies": {
    "@myorg/utils": "workspace:*",
    "@myorg/ui": "workspace:^1.0.0"
  }
}

Сводная таблица сравнения

Критерий	npm 11	Yarn 4 (Berry)	pnpm 10
Актуальная версия	11.7.0	4.9.4	10.30.1
GitHub-звёзды	~9 400	~41 500	~33 500
Загрузки/неделя (npmjs)	~99 млрд*	~7 млн	~40 млн
Хранение пакетов	Плоский hoisting	PnP (zip) / node_modules	Symlinks + hard links
Глобальный кеш между проектами	Нет (копии)	Нет (per-project)	Да (content-addressable)
Экономия диска	Базовый уровень	~30–40% (zip)	~70–80% (hard links)
Холодная установка (400 deps)	14.3 сек	6.8 сек	4.2 сек
Фантомные зависимости	Есть	Нет (PnP)	Нет (strict)
Блокировка скриптов по умолчанию	Нет	Нет	Да (v10+)
Workspaces	Базовые	Продвинутые	Продвинутые
Фильтрация монорепо	Ограниченная	Хорошая	Отличная
Zero Installs	Нет	Да (PnP)	Нет
Corepack	Поддержка	Нативная	Поддержка
Управление Node.js	Нет	Нет	Да (+Deno, Bun)
Кривая обучения	Минимальная	Средняя–Высокая	Низкая

Число загрузок npm включает автоматические установки через Node.js и CI/CD.

Практические примеры: миграция и настройка

Миграция с npm на pnpm

Переход с npm на pnpm для обычного проекта занимает несколько минут:

# 1. Установка pnpm через Corepack (рекомендуемый способ)
corepack enable
corepack prepare pnpm@latest --activate

# 2. Импорт lock-файла
pnpm import   # конвертирует package-lock.json в pnpm-lock.yaml

# 3. Удаление старых артефактов
rm -rf node_modules package-lock.json

# 4. Установка через pnpm
pnpm install

Если проект использует монорепо, потребуется создать pnpm-workspace.yaml и заменить ссылки между пакетами на протокол workspace:*.

Настройка pnpm для безопасности

Создайте или дополните .npmrc в корне проекта:

# Строгий режим зависимостей (по умолчанию в pnpm)
strict-peer-dependencies=true

# Явное разрешение скриптов только для нужных пакетов
allow-builds[]=esbuild
allow-builds[]=sharp
allow-builds[]=@prisma/client

# Блокировка свежих публикаций (защита от supply chain атак)
minimum-release-age=3d

# Автоматическая установка через Corepack
manage-package-manager-versions=true

Настройка Yarn PnP

Для нового проекта с Yarn Berry:

# Инициализация с Yarn 4
corepack enable
yarn init -2

# Настройка PnP (по умолчанию)
yarn config set nodeLinker pnp

# Установка SDK для IDE (VS Code)
yarn dlx @yarnpkg/sdks vscode

# Установка зависимостей
yarn install

Если PnP вызывает проблемы совместимости, можно переключиться на классический режим:

yarn config set nodeLinker node-modules

Конфигурация CI/CD

Пример оптимальной настройки для GitHub Actions с pnpm:

# .github/workflows/ci.yml
name: CI
on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: pnpm/action-setup@v4
        with:
          version: 10

      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: 'pnpm'

      - run: pnpm install --frozen-lockfile
      - run: pnpm -r build
      - run: pnpm -r test

Эквивалент для npm:

      - run: npm ci
      - run: npm run build
      - run: npm test

Когда выбрать npm

npm остаётся разумным выбором в следующих ситуациях:

Небольшие и средние проекты без сложной структуры зависимостей, где дисковое пространство и скорость CI не критичны.
Проекты с максимальной совместимостью — npm гарантирует работу с любыми пакетами из реестра, включая legacy-пакеты со специфическими preinstall-хуками.
Обучение и онбординг — npm входит в поставку Node.js, все туториалы и документации используют npm по умолчанию. Нулевой барьер входа.
Open-source библиотеки — для одиночных пакетов, публикуемых в реестр, npm достаточен и не создаёт дополнительных требований к контрибьюторам.

Когда выбрать Yarn

Yarn 4 (Berry) оправдан, если вам важны:

Zero Installs — если вы хотите, чтобы после git clone проект был сразу готов к запуске без install-шага. Это критично для больших команд, где разработчики часто переключают ветки.
Constraints — автоматизированные политики для монорепо (единообразие версий, обязательные поля, запрет определённых пакетов).
Существующие Yarn-проекты — если команда уже использует Yarn Berry и инвестировала в настройку PnP, миграция может не оправдать затрат.
Строгий контроль зависимостей — Hardened Mode с верификацией lock-файла и метаданных реестра.

Когда выбрать pnpm

pnpm — оптимальный выбор для большинства новых проектов в 2026 году:

Монорепозитории — pnpm предлагает наиболее мощную фильтрацию, протокол workspace:*, Config Dependencies и нативный граф зависимостей. Крупные проекты вроде Vue.js, Next.js (Vercel) и Svelte используют pnpm.
CI/CD оптимизация — 3–4x ускорение установки зависимостей по сравнению с npm напрямую сокращает время и стоимость пайплайнов.
Экономия диска — на машине разработчика с 5–10 проектами pnpm экономит гигабайты за счёт глобального хранилища.
Безопасность — блокировка скриптов по умолчанию, minimumReleaseAge и строгая модель зависимостей делают pnpm наиболее защищённым менеджером из тройки.
Простота миграции — pnpm использует стандартный node_modules (через symlinks), поэтому практически все инструменты работают без дополнительной настройки, в отличие от Yarn PnP.

Тренды и экосистема

Стоит упомянуть несколько значимых тенденций 2025–2026 годов.

Corepack — встроенный в Node.js менеджер менеджеров пакетов — стабилизируется и становится рекомендуемым способом установки Yarn и pnpm. Поле packageManager в package.json гарантирует, что все участники команды используют одну и ту же версию:

{
  "packageManager": "pnpm@10.30.1"
}

pnpm как менеджер рантаймов — в 2025 году pnpm расширил функциональность управления рантаймами, добавив поддержку Node.js, Deno и Bun. Это позволяет заменить nvm/fnm для управления версиями Node.js:

{
  "pnpm": {
    "executionEnv": {
      "nodeVersion": "22.14.0"
    }
  }
}

Bun как четвёртый игрок — Bun набирает популярность благодаря рекордной скорости установки (до 18x быстрее npm), но пока отстаёт по зрелости монорепо-инструментов и стабильности. В контексте данного сравнения мы сосредоточились на тройке зрелых инструментов, но Bun стоит отслеживать как перспективную альтернативу.

Заключение

В 2026 году pnpm выходит на позицию рекомендуемого пакетного менеджера по умолчанию для новых JavaScript/TypeScript-проектов. Он сочетает максимальную производительность, радикальную экономию диска, строгую модель безопасности и лучшие инструменты для монорепозиториев — при этом сохраняя совместимость со стандартной структурой node_modules и минимальным барьером входа.

Yarn 4 остаётся сильным выбором для команд, инвестировавших в экосистему Berry, и для проектов, которым критична функциональность Zero Installs или Constraints. Однако сложность настройки PnP и необходимость IDE-плагинов создают дополнительный порог входа.

npm 11 по-прежнему «просто работает» и является разумным выбором для небольших проектов, обучения и ситуаций, где совместимость важнее оптимизации. Усиленная безопасность (сессионные токены, OIDC) адресует главные уязвимости прошлого.

Какой бы менеджер вы ни выбрали, зафиксируйте его версию через Corepack и packageManager в package.json, используйте --frozen-lockfile в CI и регулярно обновляйте зависимости. Инструмент — лишь часть уравнения; дисциплина управления зависимостями важнее конкретного менеджера.

pnpm vs npm vs Yarn в 2026: какой пакетный менеджер выбрать