Comments 19
В PNPM реализована возможность устанавливать пакеты с произвольными именами. Например: .pnpm add lodash@npm:awesome-lodash
Это обычный алиасинг, который поддерживается в npm и yarn. Синтаксис тот же самый.
Стоит уточнить, что от node_modules избавились не в Yarn2, а в Yarn PnP. В актуальной версии все ещё присутствует возможность использовать node_modules. Более того, при миграции с npm, по умолчанию будет использован как раз-таки nodeLinker
Стоит добавить, что в отличии от npm, в yarn важно использовать ту же самую версию т.к. при разных версиях yarn с одинаковым lock файлом мы получим разный результат.
Если речь про разницу в мажорных версиях, то конечно, однако в моем понимании это очевидно. В Yarn 2 по умолчанию используется другой формат lockfile. Но если взять yarn 1 с разными минорными версиями, проблем возникнуть не должно, во всяком случае я с таким не сталкивался. Минорные версии - это когда добавляется функциональность обратно-совместимым образом.
Спасибо за замечание.
Для npm тоже важно использовать одну и ту же версию. Они производят разные lock-файлы.
В статье очень много неточностей, например:
PNPM работает в несколько раз быстрее, чем NPM и YARN, потребляет меньше интернет-трафика. Также он более надежен, так как проверяет валидность пакетов через хэши.
Это делает и npm, и yarn. У них тоже есть хэши в лок файлах.
Так же не описаны правильные команды для восстановления пакетов по лок-файлам.
npm ci // вместо npm i как видно на скриншоте с логами тестов
yarn install --frozen-lockfile
pnpm i --frozen-lockfile
Годный материал, а главное в тему и вовремя.
Периодически приходится сталкиваться с Node.js и его прожорливым пакетным менеджером. Теперь появилось понимание как можно это лечить.
В статье нет упоминания, что pNPM - это protestware, его основной разработчик не придерживается принципов нейтральности, а инфраструктура недоступна как минимум из РФ.
Советовать его как реальную альтернативу без этих оговорок, на мой взгляд, опасно, потому что в него со средним риском могут быть вшиты закладки сколь угодной степени деструктивности, реагирующие на локаль системы или на геопозицию. Для разработчиков, не использующих ру-локаль и находящихся за пределами РФ и РБ, этих рисков вероятно нет.
В РБ pnpm.io тоже не доступен.
У кого-то был положительный опыт использования yarn2/pnp?
Благодарю за статью. Ещё бы немного раскрыть тему смены пакетного менеджера в проекте. Например загрузил проект, а он собран pnpm, если у тебя yarn v1 или v2, какие риски это несёт? Судя по статье подходы разняться и вот думаю — если клонирую проект, стоит ли его собирать "родным" менеджером?
И да хотел перейти на pnpm в конце статьи, а после комментария Rive о разработчике решил повременить.
Что такое менеджер пакетов, и в чем разница YARN, NPM, PNPM?