pnpm — быстрый менеджер пакетов вместо npm и yarn

Claude Code только что предложил поправить компонент, и следующим шагом просит запустить npm install, чтобы подтянуть новую библиотеку. Экран замирает на минуту, потом на две. Пока установка идёт, ты сидишь и смотришь на крутящийся индикатор, хотя минуту назад уже ставил похожий набор пакетов в соседнем проекте. Это тот самый момент, где на сцену выходит pnpm — менеджер пакетов, который делает ровно то же самое, что npm, но заметно быстрее и экономнее по месту на диске.

Что такое менеджер пакетов вообще, мы уже разбирали в статье про Node.js — это программа, которая скачивает и устанавливает библиотеки (их называют зависимостями), нужные твоему проекту для работы. npm — базовый менеджер пакетов, который ставится вместе с Node.js автоматически. pnpm — отдельный инструмент, который делает ту же работу, но по-другому устроен внутри. Ниже — чем именно.

Что такое pnpm и чем он отличается от npm и yarn

pnpm расшифровывается как «performant npm» — производительный npm. Это менеджер пакетов с открытым кодом, который читает тот же файл package.json, понимает те же команды, но хранит скачанные библиотеки иначе.

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

Когда npm ставит пакет, он копирует файлы этого пакета в папку node_modules твоего проекта. Если у тебя десять проектов и все используют, скажем, React одной и той же версии, npm скачает и сохранит React десять раз — по разу на каждый проект. Каждая копия занимает место на диске, и суммарно это может набегать на гигабайты, особенно с учётом того, что каждый пакет тянет за собой ещё и свои собственные зависимости.

pnpm устроен по-другому. Он скачивает пакет один раз и кладёт его в общее хранилище на диске — это называется content-addressable store, то есть хранилище, где каждый файл лежит по адресу, который вычисляется из его содержимого. А в папку node_modules каждого конкретного проекта pnpm не копирует файлы заново, а создаёт симлинки — ссылки на файлы в общем хранилище, которые операционная система показывает так, будто файл лежит именно тут.

Аналогия: у тебя дома десять комнат, и в каждой нужна одна и та же книга рецептов. npm покупает и кладёт по экземпляру книги в каждую комнату — десять книг, десять мест на полке. pnpm покупает одну книгу, ставит её на общую полку в коридоре, а в каждую комнату вешает табличку с указателем «книга рецептов — вот здесь». Табличка весит несколько граммов, а книга физически лежит одна.

Как устроено общее хранилище

Внутри общего хранилища pnpm использует ссылки на уровне файловой системы — на разных операционных системах это делается чуть по-разному (симлинки, жёсткие ссылки или точки соединения папок на Windows), но суть одна: данные лежат на диске один раз, а операционная система умеет показывать их сразу в нескольких местах. В папке node_modules каждого проекта pnpm создаёт скрытую вложенную структуру .pnpm, где выстраивает точное дерево зависимостей именно для этого проекта, а уже из неё раскладывает нужные ссылки на верхний уровень node_modules, с которым работают твой код и инструменты сборки. Для повседневной работы эти детали держать в голове не обязательно: команды и результат работы точно такие же, как если бы файлы лежали обычным образом.

Посмотреть, где физически находится хранилище на твоём компьютере, можно командой:

pnpm store path

pnpm workspaces — несколько пакетов в одном проекте

Если проект со временем разрастётся до нескольких связанных частей — например, отдельно код игры и отдельно общий набор утилит, которым пользуются несколько твоих проектов, — pnpm умеет управлять ими как единым целым через файл pnpm-workspace.yaml, в котором просто перечисляются папки-пакеты. Такой набор связанных пакетов в одном репозитории называют монорепозиторием. У npm и yarn тоже есть похожий механизм workspaces, но именно у pnpm экономия места на диске работает и здесь: общие зависимости между пакетами внутри монорепозитория берутся из одного и того же общего хранилища, а не дублируются под каждый пакет отдельно. Для одиночного учебного проекта эта возможность не понадобится, но полезно знать, что она есть, если решишь позже разделить проект на несколько частей.

Из этого устройства вытекают два практических следствия. Во-первых, экономия места на диске: если у тебя несколько проектов с пересекающимися зависимостями, суммарный объём папок node_modules у pnpm получается заметно меньше, чем у npm, потому что общие пакеты не дублируются. Во-вторых, скорость установки: когда пакет уже лежит в общем хранилище (например, потому что ты ставил его в другом проекте), pnpm не скачивает его из интернета заново — он просто создаёт симлинк, а это происходит почти мгновенно.

Yarn — ещё один популярный менеджер пакетов, который тоже быстрее классического npm. Но yarn по умолчанию всё ещё копирует файлы пакетов в node_modules каждого проекта, поэтому не даёт такой экономии места, как pnpm с его общим хранилищем. Разберём это подробнее в отдельном разделе ниже с таблицей.

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

Ещё один нюанс, который стоит знать заранее: сама папка node_modules в проекте на pnpm выглядит непривычно, если заглянуть в неё файловым менеджером. Часть «пакетов» там на самом деле окажутся ссылками, а не обычными папками с файлами — операционная система показывает их содержимое так же, как обычные файлы, но ярлычок или иконка могут отличаться. Пугаться этого не стоит: для кода и инструментов сборки разницы нет, они обращаются к файлам обычным способом и не замечают, что перед ними ссылка, а не оригинал.

Почему это важно именно при работе с ИИ-агентами

Когда ты пишешь код сам, ты меняешь зависимости проекта не так уж часто — установил один раз нужный набор библиотек и работаешь месяцами. С ИИ-агентами вроде Claude Code картина другая. Агент активно экспериментирует: пробует добавить библиотеку для анимаций, потом решает, что она не подходит, убирает её и ставит другую, потом добавляет ещё три пакета для тестов. Каждое такое действие означает новый запуск установки зависимостей.

Ты продолжаешь работать в диалоге с агентом, а не наблюдаешь за прогресс-баром — но каждая секунда установки это секунда, которую агент тратит на выполнение команды вместо того, чтобы перейти к следующему шагу задачи. Если install идёт быстро, диалог с ИИ течёт без разрывов: ты сформулировал задачу, агент поправил код, поставил зависимости, показал результат. Если install тянется по минуте на каждое изменение, разрывов становится много, а суммарное время ожидания за сессию накапливается заметно.

Есть и вторая причина, специфичная именно для агентных сценариев. Иногда агенту нужно пересоздать node_modules с нуля — например, после того как он почистил кэш, переключил ветку git или диагностирует странную ошибку, которая могла быть вызвана повреждённой установкой пакетов. Команда «удалить node_modules и поставить заново» с npm означает полную повторную закачку всех пакетов из интернета. С pnpm большая часть пакетов уже лежит в общем хранилище на диске, и повторная установка превращается в создание симлинков — что на порядок быстрее скачивания.

Если ты проходишь курс skillmake и параллельно держишь несколько учебных проектов — например, основную «Змейку» и пробную копию для эксперимента с новой функцией — экономия от pnpm складывается вдвойне: меньше места на диске компьютера и быстрее отклик агента на каждую правку зависимостей.

Несколько сессий агента на одном компьютере

Похожий эффект возникает, если ты запускаешь несколько сессий Claude Code параллельно — например, каждую в отдельной рабочей папке (worktree) со своей веткой git, чтобы сессии не мешали друг другу. У каждой такой папки своя собственная node_modules, потому что рабочие папки физически разные, но набор пакетов в них чаще всего один и тот же: тот же React, тот же движок игры, те же инструменты сборки. С npm это означает установку одного и того же набора библиотек заново в каждой отдельной папке. С pnpm все эти копии всё равно опираются на одно и то же общее хранилище на диске, поэтому установка в новой рабочей папке занимает секунды, даже если это уже пятая параллельная копия одного и того же проекта.

Как начать использовать pnpm на практике

Установка pnpm занимает одну команду в терминале. Самый простой способ — раз у тебя уже есть Node.js (а если ещё нет, сначала пройди установку из статьи про Node.js) — воспользоваться встроенным в Node.js менеджером corepack:

corepack enable
corepack prepare pnpm@latest --activate

Это активирует pnpm через corepack — инструмент, который идёт в комплекте с современными версиями Node.js и умеет подключать менеджеры пакетов без отдельной установки. Альтернативный способ — поставить pnpm напрямую через npm:

npm install -g pnpm

После установки проверь, что всё сработало:

pnpm -v

Если увидел номер версии — pnpm готов к работе. Дальше самое приятное: команды pnpm почти один в один повторяют команды npm, только с заменой слова npm на pnpm.

Обрати внимание на последнюю строку — команда pnpm build, которую многие ищут именно в такой формулировке. В pnpm необязательно писать run перед именем скрипта: если скрипт называется build, dev или test и не совпадает с одной из встроенных команд pnpm, можно запускать его напрямую, короче, чем в npm. Аналогично pnpm dev вместо npm run dev.

Если тебе привычнее, слово run можно писать и в pnpm — pnpm run build тоже сработает, разницы в результате нет.

Ещё несколько команд, которые пригодятся по мере работы:

• pnpm dlx название-пакета — аналог npx: запускает пакет один раз, без постоянной установки в проект. Пригодится для одноразовых генераторов кода и утилит.
• pnpm add -g название-пакета — установить пакет глобально, чтобы он был доступен из любой папки в терминале.
• pnpm update — обновить зависимости проекта до версий, разрешённых в package.json.
• pnpm outdated — посмотреть список пакетов, для которых вышли более новые версии.
• pnpm store status — проверить состояние общего хранилища на диске.
• pnpm store prune — удалить из хранилища пакеты, которые больше не используются ни в одном проекте, и освободить место.
• pnpm why название-пакета — узнать, откуда в проекте взялся конкретный пакет и какая зависимость его затянула. Пригодится, когда видишь в node_modules библиотеку, которую сам явно не устанавливал, и хочешь понять источник.

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

Как читать вывод команды install

Во время установки pnpm показывает в терминале строку прогресса, где отдельно считается, сколько пакетов взято из общего хранилища (обычно подписано как reused или похоже), а сколько скачано заново из интернета. Чем выше доля «взято из хранилища» относительно «скачано», тем больше времени и трафика pnpm сэкономил именно в этой установке благодаря тому, что нужные пакеты уже лежали на диске с прошлого раза.

Фиксация версии pnpm в проекте

Есть практическая деталь, которая упрощает совместную работу над проектом. В package.json можно указать поле packageManager с точной версией pnpm, например "packageManager": "pnpm@9.0.0". Тогда corepack сам подставит именно эту версию для всех, кто открывает проект — и для тебя, и для ИИ-агента, и для любого, кто присоединится к проекту позже. Установка проходит одной и той же версией менеджера пакетов, без сюрпризов из-за разницы версий на разных компьютерах.

Совместимость с существующими проектами

pnpm понимает обычный package.json — тот самый файл-паспорт проекта, где перечислены зависимости, скрипты и метаданные. Тебе не нужно переписывать этот файл, чтобы перейти на pnpm: он читает его так же, как читает npm.

Разница появляется в файле блокировки версий (lock-файле). npm использует package-lock.json, yarn — yarn.lock, а pnpm ведёт собственный файл pnpm-lock.yaml. Лок-файл фиксирует не только версии пакетов из package.json, но и точные версии всех их внутренних зависимостей — это гарантирует, что установка даст одинаковый результат у тебя, у агента и на любом другом компьютере. Переход с npm на pnpm в уже существующем проекте делается так:

1. Убедись, что pnpm установлен (pnpm -v должен показать номер версии).
2. Удали старую папку node_modules и старый package-lock.json (если он был) — они больше не понадобятся.
3. Запусти pnpm install — pnpm прочитает package.json, скачает нужные пакеты в общее хранилище (или возьмёт уже скачанные оттуда) и создаст свой pnpm-lock.yaml.
4. Проверь, что проект по-прежнему запускается: выполни привычные команды вроде pnpm dev или pnpm build и убедись, что ошибок нет.
5. Закоммить новый pnpm-lock.yaml в git вместо старого лок-файла.

Держать в проекте одновременно package-lock.json и pnpm-lock.yaml не стоит — разные менеджеры пакетов не читают чужие лок-файлы, и наличие обоих только путает, какой из них актуален. Выбери один менеджер пакетов на проект и придерживайся его.

Если проект уже используешь ты один и тебя устраивает npm — переходить на pnpm не обязательно, это не критичное обновление, а вопрос удобства и скорости. Если же ты ведёшь несколько параллельных учебных проектов через агента, разница станет заметна довольно быстро.

Когда могут возникать проблемы

У более строгой структуры node_modules в pnpm есть обратная сторона. npm традиционно «поднимает» все зависимости — в том числе зависимости зависимостей — в общую корневую папку node_modules, и из-за этого пакет иногда умудряется случайно найти и использовать библиотеку, которую сам явно не указывал как свою зависимость, а получил окольным путём через чужую зависимость. Это называется фантомными зависимостями — пакет как бы есть в проекте и работает, а в package.json его нет.

pnpm по умолчанию не даёт такой поблажки: доступны только те пакеты, которые явно перечислены в зависимостях. Это в целом полезнее — меньше сюрпризов и более честная картина, что на самом деле нужно проекту. Но у некоторых старых пакетов зависимости описаны неточно: авторы полагались на то, что нужная библиотека и так «случайно» окажется доступна благодаря плоской структуре npm. С pnpm такой пакет иногда падает с ошибкой, что не может найти нужный модуль, хотя с npm тот же код работал без проблем.

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

Ещё одна особенность, с которой можно столкнуться: из соображений безопасности pnpm по умолчанию не запускает автоматически скрипты, которые пакет хочет выполнить прямо во время установки (например, скрипт с именем postinstall), если пакет не одобрен явно. Смысл в том, что скачанный из интернета код теоретически может исполнить что угодно на твоём компьютере в момент установки, и pnpm блокирует эту возможность заранее для незнакомых пакетов. Если после установки что-то работает не так, как ожидалось — особенно у пакетов, которые собирают нативные модули под конкретную операционную систему, — стоит проверить список пакетов, ожидающих одобрения, командой pnpm approve-builds. Она покажет, какие зависимости хотят выполнить скрипт при установке, и даст явно разрешить нужные.

Отдельно pnpm строже, чем npm, относится и к так называемым peer-зависимостям — пакетам, которые библиотека ожидает найти в проекте, но не устанавливает сама, полагаясь на то, что их поставишь ты. Если версии не совпадают, pnpm обычно выводит предупреждение прямо по ходу установки, тогда как npm в похожей ситуации мог промолчать. Это не поломка, а более честная диагностика: лучше увидеть предупреждение сразу, чем ловить непонятную ошибку в рантайме позже.

Если проект открывают на нескольких компьютерах — например, ты работаешь дома и параллельно на другом устройстве, — стоит убедиться, что версия pnpm везде одна и та же: разные major-версии pnpm иногда по-разному форматируют pnpm-lock.yaml, и это может приводить к постоянным изменениям в файле блокировки при каждом коммите просто из-за разницы версий менеджера, а не из-за реальных изменений зависимостей. Поле packageManager в package.json, о котором говорилось выше, как раз и снимает эту проблему.

Для типичного учебного проекта на курсе, где зависимостей немного и они современные, такие конфликты возникают редко.

Подходит ли pnpm для учебного проекта вроде «Змейки»

Да, pnpm без проблем справится с проектом уровня «Змейки» — там зависимостей немного, и установка любым менеджером пакетов займёт секунды. Разница в скорости между npm и pnpm становится заметна не на маленьком одиночном проекте, а тогда, когда на компьютере одновременно живёт несколько проектов с общими библиотеками или когда сам проект вырастает и обрастает десятками зависимостей.

Если ты проходишь курс и держишь только «Змейку», выгода от перехода на pnpm будет скромной — установка и так быстрая. Но если параллельно экспериментируешь с несколькими вариантами проекта, готовишь что-то к модулю про сторы или пробуешь идеи для собственного приложения после курса, экономия времени и места на диске начинает ощущаться сразу.

Практический пример: модуль курса про качество добавляет в «Змейку» магазин скинов, звук и подготовку к PWA — это новые зависимости поверх уже установленных. Если рядом лежит вторая копия проекта для эксперимента с другим набором скинов, обе копии используют одни и те же базовые библиотеки. С npm агенту придётся заново скачать их для второй копии. С pnpm вторая установка почти мгновенно возьмёт уже скачанные файлы из общего хранилища, и ты быстрее увидишь результат эксперимента.

Короткое сравнение с yarn

yarn появился раньше pnpm и тоже решал задачу ускорения по сравнению с классическим npm — за счёт параллельной закачки пакетов и собственного кэша. Но структура node_modules у yarn (в его классическом, наиболее распространённом режиме работы) устроена так же, как у npm: файлы пакетов копируются в каждый проект отдельно. Общий кэш ускоряет повторные установки, но не устраняет дублирование файлов на диске так, как это делает общее хранилище pnpm с симлинками.

Есть и более новая версия yarn — её называют Yarn Berry, в отличие от классической Yarn Classic. У Yarn Berry есть необычный режим работы Plug'n'Play, который вообще отказывается от привычной папки node_modules и хранит карту зависимостей в отдельном файле. Это другой подход к той же проблеме скорости и места на диске, но он требует, чтобы используемые библиотеки и инструменты сборки были совместимы именно с этим режимом, а часть старых пакетов с ним конфликтует. Для новичка это лишнее усложнение: pnpm даёт похожую экономию, но без отказа от привычной структуры node_modules, поэтому переход на него спокойнее.

Сравнение npm, yarn и pnpm

Стоит ли переходить прямо сейчас

Если сомневаешься, ориентируйся на три признака, по которым pnpm точно стоит попробовать:

• на компьютере уже больше одного проекта на Node.js, и они используют похожие библиотеки;
• агент часто переустанавливает зависимости в процессе работы над задачей, а ты замечаешь паузы;
• место на диске компьютера ощутимо тает от накопившихся папок node_modules.

Если ни один из пунктов пока не про тебя — оставайся на npm, он никуда не денется и прекрасно справляется с одиночным небольшим проектом. Перейти на pnpm можно в любой момент позже, когда экономия времени и места станет ощутимой, а не только теоретической.

Частые вопросы

pnpm заменяет npm полностью?

Нет, скорее дополняет выбор. npm остаётся стандартным менеджером пакетов, который идёт вместе с Node.js, и ничего не сломается, если продолжать пользоваться им. pnpm — альтернатива для тех, кому важна скорость установки и экономия места на диске, особенно при работе с несколькими проектами одновременно.

Нужно ли переписывать package.json при переходе на pnpm?

Нет. package.json — универсальный формат, его понимают npm, yarn и pnpm одинаково. Меняется только лок-файл: вместо package-lock.json появляется pnpm-lock.yaml, и его нужно пересоздать заново командой pnpm install.

Claude Code сам разберётся, какой менеджер пакетов использовать?

Обычно да — агент смотрит на существующие файлы проекта (например, наличие pnpm-lock.yaml или package-lock.json) и подстраивается под уже выбранный менеджер. Если проект новый и менеджер ещё не выбран, можно прямо попросить агента поставить зависимости через pnpm — например, сформулировать задачу так: «используй pnpm вместо npm для установки зависимостей этого проекта». Дальше агент сам вызовет pnpm install и последующие команды в нужном формате.

Что делать, если пакет не устанавливается через pnpm с ошибкой?

Сначала проверь документацию пакета — иногда там прямо написано про особенности работы с pnpm. Если это не помогает, попробуй установить пакет отдельно как явную зависимость проекта командой pnpm add название-пакета, а не полагаться на то, что он подтянется через другую библиотеку. Если ошибка связана со скриптом установки, который pnpm заблокировал из соображений безопасности, проверь список ожидающих одобрения пакетов командой pnpm approve-builds.

pnpm работает одинаково на Windows, macOS и Linux?

Да, pnpm кроссплатформенный и устанавливается одинаково через corepack или npm на всех трёх системах: команды pnpm install, pnpm add, pnpm run работают идентично. Механизм ссылок на общее хранилище поддерживается везде, хотя технически на Windows он устроен немного иначе, чем на macOS и Linux — для пользователя это не создаёт заметной разницы в работе.

Можно ли использовать pnpm вместе с автотестами и CI?

Да, pnpm поддерживается в большинстве систем непрерывной интеграции — детали настройки автотестов и CI разобраны в статье про npm test и CI, принципы там применимы и к pnpm с заменой команд по таблице выше.

Если ты ещё не устанавливал Claude Code, инструкция по установке ждёт в отдельной статье — как установить Claude Code. А после того как агент и Node.js уже на месте, переход на pnpm — это одна команда в терминале, которая делает ожидание установок короче на всех твоих проектах разом.