Сравнение менеджеров пакетов JavaScript: Npm, Yarn и Pnpm

В области менеджеров пакетов есть три основных игрока:

• npm

• Yarn

• High-Performance npm (pnpm).

На самом деле у нас во всех менеджерах пакетов реализованы в основном схожие функции, поэтому вы, скорее всего, решите, какой из них использовать, основываясь на нефункциональных требованиях. Менеджер пакетов. , например скорость установки, потребление памяти или практичность.

Конечно, способы использования каждого менеджера пакетов будут разными, но все они имеют в основном одинаковые концепции. Все вышеперечисленные менеджеры пакетов могут выполнять следующие команды:

• Чтение и запись данных.
• Пакетную установку или обновление всех зависимостей.
• Добавление, обновление и удаление зависимостей.
• Запуск сценариев.
• Публикацию пакетов

. Однако, несмотря на это, менеджеры пакетов различаются внутри. Традиционно npm и Yarn устанавливали зависимости в плоскую папку node_modules. (Обратите внимание на порядок: сначала yarn укладывается в плитку, а npm раньше был рекурсивным). Но укладка плитки также может вызвать ряд проблем с безопасностью.

• Неопределенность структуры зависимости.

• Сам алгоритм выравнивания очень сложен и требует много времени.

• Пакеты с объявленными зависимостями

• по-прежнему могут быть несанкционированно доступны в проекте.

Поэтому pnpm ввел некоторые новые концепции в папку node_modules для более эффективного хранения зависимостей. Yarn Berry идет еще дальше, полностью отказываясь от режима (PnP) node_modules (подробнее об этом в другой статье).

Краткая история пакетов JavaScript

Самым ранним выпущенным менеджером пакетов был npm еще в январе 2010 года. Он установил основные принципы работы менеджеров пакетов сегодня. Но поскольку npm существует уже более 10 лет, почему есть другой вариант? Вот несколько основных причин, почему это может быть так:

• Структура папок node_modules имеет разные алгоритмы разрешения зависимостей (вложенные и мозаичные, node_modules и режим PnP) и
• разные методы подъема зависимостей ( hoisting ).
• Различные форматы locking (различная производительность, например, тот, который написан самой yarn ).
• Пакет дискового хранилища. Другой файл. форматы (различная эффективность использования пространства).
• Различная поддержка проектов с несколькими пакетами (так называемых workspaces ), что влияет на удобство обслуживания и скорость monorepos
• Различные потребности в новых инструментах и ​​командах (различные потребности в расширяемости с помощью плагинов и инструментов сообщества).
• Конфигурируемость и гибкость по-другому.

Давайте углубимся в история того, как эти аспекты были определены после возникновения npm , как Yarn Classic решила некоторые из этих проблем, как pnpm расширила эти концепции и как Yarn Berry , как преемник Yarn Classic ломает эти традиционные концепции и процессы.

Pioneer npm

npm — создатель менеджеров пакетов. Многие ошибочно полагают, что npm — это аббревиатура от «Менеджер пакетов Node», но это не так.

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

В 2020 году GitHub приобрел npm, поэтому в принципе теперь npm находится под управлением Microsoft. На момент написания последней основной версией является v8, выпущенная в октябре 2021 года.

Инноватор Yarn Classic

В октябре 2016 года Facebook объявил о партнерстве с Google и рядом других компаний для разработки нового менеджера пакетов (engineering.fb.com/2016/10/11/…) для решения проблемы существовавшей на тот момент согласованности npm. проблемы безопасности и производительности. Они назвали замену Yarn.

Хотя Yarn по-прежнему спроектирован и спроектирован на основе многих концепций и процессов npm , Yarn оказал значительное влияние на область менеджеров пакетов. По сравнению с npm , Yarn распараллеливает операции для ускорения процесса установки, что было основной проблемой в более ранних версиях npm .

Yarn установил более высокие стандарты чтения и записи, безопасности и производительности, а также изобрел множество концепций (позже npm также сделал много улучшений для этого), в том числе:

• monorepo поддерживает
• кэширование, установку
• блокировки Locking
• для автономной загрузки
(Locking).

Yarn v1 в режиме обслуживания в 2020. С тех пор серия v1.x считается устаревшей и переименована в Yarn Classic . Его преемник Yarn v2 (Berry) теперь является более активной веткой разработки.

Более эффективный pnpm

Версия 1 pnpm была выпущена в 2017 году Золтаном Кочаном. Это замена npm , поэтому, если у вас есть проект npm , вы можете сразу использовать pnpm !

Основная причина создания pnpm заключается в том, что npm и Yarn очень избыточны с точки зрения структур хранения зависимостей, используемых в проектах. Хотя Yarn Classic имеет преимущество в скорости по сравнению с npm , он использует тот же метод разрешения зависимостей, которого нет в pnpm : npm и Yarn Classic используют hoisting для выравнивания своих node_modules .

Вместо оптимизации предыдущей структуры pnpm предлагает другую стратегию разрешения зависимостей: a. структура хранения с адресацией содержимого. Папка node_modules , созданная этим методом, фактически зависит от каталога ~/.pnpm-store/ , который хранится глобально в основной папке. Каждая версия зависимостей физически сохраняется один раз в этой папке каталога, образуя единый исходный адрес для экономии значительного дискового пространства.

Структура node_modules представляет собой вложенную структуру зависимостей, созданную с помощью symlinks (где каждый файл/пакет в папке хранится через жесткую ссылку). Следующий рисунок из официальной документации иллюстрирует это. (Картинки для заполнения: мягкие и жесткие ссылки)

Влияние pnpm видно в отчете за 2021 год: благодаря инновациям в области хранения с адресацией по содержимому конкуренты стремятся перенять концепции pnpm , такие как структура символических ссылок и эффективное управление дисками пакетов.

Yarn (v2, Berry), заново изобретающий колесо с помощью Plug'n'Play

Yarn 2, был выпущен в январе 2020 года и был объявлен серьезным обновлением оригинальной Yarn . Команда Yarn называет его Yarn Berry , чтобы было более очевидно, что это, по сути, новый менеджер пакетов с новой базой кода и новыми принципами.

Главным нововведением Yarn Berry является подход Plug-and-Play (PnP) в качестве стратегии восстановления node_modules. Вместо стратегии создания node_modules создайте файл .pnp.cjs с таблицей поиска зависимостей, что позволяет более эффективно обрабатывать зависимости, поскольку это отдельный файл, а не структура вложенных папок. Кроме того, каждый пакет хранится в папке в виде zip-файла вместо .yarn/cache/ и занимает меньше места на диске, чем node_modules .

Все эти изменения произошли так быстро, что вызвали много споров после выхода. Такие критические изменения в PnP требуют, чтобы сопровождающие обновляли свои существующие пакеты, чтобы они были совместимы с ним. Использовать новый подход PnP по умолчанию и вернуться к node_modules изначально было непросто, что привело к тому, что многие известные разработчики не рассматривали его и публично критиковали Yarn 2.

С тех пор команда Yarn Berry решила множество проблем в своих последующих выпусках. Чтобы решить проблемы несовместимости PnP, команда предоставила способ легко изменить режим работы по умолчанию. С помощью плагина node_modules для возврата к традиционному подходу node_modules требуется всего одна строка конфигурации.

Кроме того, экосистема JavaScript со временем обеспечивает все большую поддержку PnP, и, как вы можете видеть из этой таблицы совместимости, некоторые крупные проекты начали использовать Yarn Berry .

Несмотря на то, что Yarn Berry еще молод, он уже оказывает влияние на сферу менеджеров пакетов — pnpm принял подход PnP в конце 2020 года.

Рабочий процесс установки

Менеджер пакетов сначала должен быть установлен в локальной системе и системе CI/CD каждого разработчика.

npm

npm поставляется с Node.js , поэтому никаких дополнительных действий не требуется. Помимо загрузки установщика Node.js для вашей операционной системы, стало обычной практикой использовать инструменты CLI для управления версиями программного обеспечения. В контексте Node очень удобной утилитой стал Node Version Manager (nvm) или Volta.

Yarn Classic и Yarn Berry

Вы можете установить Yarn 1 разными способами, например, как пакет npm : .$ npm i -g yarn

Для перехода с Yarn Classic на Yarn Berry рекомендуемый метод:

• Установите или обновите Yarn Classic до

To. обновитесь до последней современной

• версии

,

• используя команду

  Yarn Set Version berry.

Однако рекомендуемый способ установки Yarn Berry здесь — через Corepack.

Corepack был создан разработчиками Yarn Berry. Первоначально эта инициатива называлась Package Manager Manager (pmm) и была объединена с Node в LTS v16.

С помощью Corepack Node становится альтернативным менеджером пакетов для npm , который не нужно устанавливать «отдельно», поскольку он включает двоичные файлы Yarn Classic , Yarn Berry и pnpm . Эти прокладки позволяют пользователям запускать команды Yarn и pnpm без их предварительной установки и без нарушения дистрибутива Node.

Corepack поставляется с предустановленным Node.js ≥ v16.9.0. Однако для более старых версий Node вы можете использовать ⬇️

npm install -g corepack,

чтобы включить Corepack перед его использованием. В этом примере показано, как активировать его в Yarn Berry v3.1.1.

# сначала вам нужно зарегистрироваться
$ corepack включить
# прокладка установлена, но необходимо активировать конкретную версию
$ corepack подготовить [email protected] --activate

pnpm

Вы можете установить pnpm как пакет npm : $ npm i -g pnpm . Вы также можете установить pnpm с помощью Corepack:

$ corepack подготовить [email protected] --activate

структуру проекта

В этом разделе вы кратко увидите основные функции различных менеджеров пакетов. Вы можете легко узнать, какие файлы участвуют в настройке конкретного менеджера пакетов и какие файлы создаются на этапе установки.

Все менеджеры пакетов хранят всю важную метаинформацию в файле манифеста проекта package.json. Кроме того, файлы конфигурации корневого уровня можно использовать для настройки различных частных пакетов или различных конфигураций разрешения зависимостей.

На этапе установки dependencies сохраняются в файловой структуре, такой как node_modules , и создается файл locking . В этом разделе не рассматриваются настройки рабочей области, поэтому во всех примерах показано только одно место, где хранятся зависимости.

npm,

используя $ npm install или более короткую версию $ npm i сгенерирую файл package-lock.json и папку node_modules . Существуют также настраиваемые файлы, такие как .npmrc , которые можно разместить в корневом каталоге. Дополнительную информацию о locking файлов смотрите в следующем разделе.

.
├── node_modules/
├── .npmrc
├── package-lock.json
└── package.json

Yarn

, запуская $ yarn создаст файл yarn.lock и папку node_modules . Файлы .yarnrc также могут быть параметрами конфигурации, а Yarn Classic также поддерживает файлы .npmrc . Альтернативно вы можете использовать папку кэша .yarn/cache/ и последнюю версию Yarn Classic хранящуюся локально в .yarn/releases/ .

.
├── .пряжа/
│ ├── кэш/
│ └── релизы/
│ └── пряжа-1.22.17.cjs
├── node_modules/
├── .yarnrc
├── package.json
└── Yarn.lock

Yarn berry: node_modules

Из-за этого специального режима установки вам придется иметь дело с большим количеством файлов и папок в вашем проекте Yarn Berry чем с другими менеджерами пакетов. Некоторые из них являются необязательными, а некоторые являются обязательными.

Yarn Berry больше не поддерживает .npmrc или .yarnrc , для этого требуется .yarnrc.yml; Для традиционного рабочего процесса создания папок node_modules вы должны предоставить конфигурацию nodeLinker для использования конфигурации node_modules или pnpm (я не понимаю эту часть).

# .yarnrc.yml
nodeLinker: node-modules # или pnpm,

запускающий $ yarn установит все зависимости в папку node_modules . И создается файл yarn.lock , который более новый, но несовместим с Yarn Classic . Кроме того, для автономной установки создается папка .yarn/cache/ . Эта папка является необязательной и используется для хранения версии Yarn Berry используемой в проекте.

.
├── .пряжа/
│ ├── кэш/
│ └── релизы/
│ └── пряжа-3.1.1.cjs
├── node_modules/
├── .yarnrc.yml
├── package.json
└── Yarn.lock

Yarn berry: pnp

Независимо от того, является ли это строгим режимом или свободным режимом для PnP, выполнение $ yarn с .pnp.cjs и yarn.lock создаст .yarn/cache/ и .yarn/unplugged . Строгий PnP — режим по умолчанию. Если вы хотите настроить свободный режим, вам необходимо включить его в следующей форме⬇️:

# .yarnrc.yml.
узелЛинкер: pnp
pnpMode: свободный

В проекте PnP, помимо папки releases , папка .yarn скорее всего, также будет содержать папку sdk/ , обеспечивающую поддержку IDE. В зависимости от вашего варианта использования .yarn может даже содержать больше папок.

.
├── .пряжа/
│ ├── кэш/
│ ├── релизы/
│ │ └── пряжа-3.1.1.cjs
│ ├── SDK/
│ └── отключено/
├── .pnp.cjs
├── .pnp.loader.mjs
├── .yarnrc.yml
├── package.json
└── Yarn.lock`

pnpm

такое же, как и для проекта npm или Yarn Classic . pnpm также требует файла package.json . После установки зависимостей с помощью $ pnpm i получаю папку node_modules , но ее структура совершенно другая, поскольку ее содержимое представляет собой адресное хранилище.

pnpm также генерирует собственный файл блокировки pnp-lock.yml . Вы можете предоставить дополнительную конфигурацию, используя дополнительный файл .npmrc .

.
├── node_modules/
│ └── .pnpm/
├── .npmrc
├── package.json
└── файл блокировки pnpm-lock.yml

и зависимое хранилище

Как упоминалось в предыдущем разделе, каждый менеджер пакетов создает файлы блокировки.

В файле lock хранится точная версия каждой зависимости, установленной вашим проектом, что обеспечивает более предсказуемую и детерминированную установку. Этот файл lock важен, поскольку зависимые версии, скорее всего, будут объявлены с указанием диапазона версий (например, ≥ v1.2.5), и если вы не «заблокируете» свою версию, фактическая установленная версия может отличаться.

Файлы блокировки иногда также хранят контрольные суммы (насколько я помню, хеш), которые мы рассмотрим более подробно в разделе безопасности.

Начиная с npm v5+, блокировка файлов всегда была основной функцией npm ( package-lock.json ). В pnpm это pnpm-lock.yaml . yarn.lock в Yarn Berry появляется в новом формате YAML.

В предыдущем разделе мы видели традиционный подход к установке зависимостей в структуру папок node_modules . Это решение используется npm , Yarn Classic и pnpm ( pnpm более эффективен, чем другие).

В режиме PnP Yarn Berry работает по-другому. Вместо папки node_modules зависимости хранятся в zip-файлах в виде комбинации файлов .yarn/cache/ и .pnp.cjs .

Лучше поставить эти файлы блокировки под контроль версий, поскольку каждый член команды устанавливает одну и ту же версию, что решает проблему «работает на вашей машине и на моей».

интерфейс командной строки

В следующей таблице сравниваются различные команды CLI, доступные в npm , Yarn Classic , Yarn Berry и pnpm . Это ни в коем случае не полный список, а скорее шпаргалка. В этом разделе не рассматриваются команды, связанные с рабочим процессом.

npm и pnpm имеют множество специальных псевдонимов команд и опций, что означает, что команды могут иметь разные имена, например, $ npm install и $ npm add . Кроме того, многие параметры команды имеют сокращенные версии, например -D вместо --save-dev . В таблице все сокращенные версии я называю псевдонимами. Используя каждый из этих менеджеров пакетов, вы можете добавлять, обновлять или удалять несколько зависимостей.

Управление конфигурацией зависимостей

В этой таблице описаны команды управления зависимостями, используемые для установки или обновления всех зависимостей, указанных в package.json .

Управление конфигурацией установки

В следующем примере показано, как управлять пакетами во время разработки. Термины, используемые в таблице:

• Пакет: зависимость или двоичный
• файл. Бинарный: инструмент выполнения из node_modules/.bin/ или .yarn/cache/ (PnP).

Важно понимать, что Yarn Berry позволяет нам выполнять только в package.json или Expose

указанные двоичные файлы в bin/ file.

Общие команды

В этой таблице описаны некоторые полезные встроенные команды. Если официальной команды нет, сторонние команды обычно можно использовать через пакеты npm или плагины Yarn Berry .

Конфигурационный файл

Настройка менеджера пакетов происходит в вашем package.json и специальных файлах конфигурации.

• Определите точную версию для использования.
• Настройте частный реестр
• с определенной стратегией разрешения зависимостей.
• Сообщите менеджеру пакетов, где найти monorepo

npm

Большая часть конфигурации происходит в файле частной конфигурации .npmrc .

Если вы хотите использовать функцию workspaces npm , вам необходимо добавить поле метаданных рабочих пространств в package.json чтобы сообщить npm, где найти папку подпроекта или рабочей области.

// ...
  "рабочие места": [
    «крючки»,
    "утилиты"
  ]
}

Каждый менеджер пакетов может использовать общедоступный реестр npm . Вероятно, вы захотите использовать их повторно, не публикуя в публичном реестре. Вы можете настроить это для конфиденциальности реестра в вашем файле .npmrc . (Практически у всех сейчас есть частные исходники)

# .npmrc
@doppelmutzi:registry=https://gitlab.doppelmutzi.com/api/v4/projects/41/packages/npm/

Существует множество вариантов конфигурации npm , лучше всего ознакомиться с ними в документации.

Yarn

Вы можете установить workspaces yarn в package.json (должен быть частный пакет).

{
  // ...
  «частное»: правда,
  "workspaces": ["workspace-a", "workspace-b"]
}

Любая дополнительная конфигурация сохраняется в файле .yarnrc . Распространенным вариантом конфигурации является установка yarn-path: он заставляет каждого члена команды использовать указанную двоичную версию. yarn-path указывает на папку, содержащую определенную версию Yarn (например, .yarn/releases/ ). Установить унифицированную версию Yarn Classic можно с помощью команды (classic.yarnpkg.com/en/docs/cli…).

Yarn berry

Настройка workspaces в Yarn Berry аналогична настройке в Yarn Classic ( package.json ). Большая часть конфигурации Yarn Berry находится в .yarnrc.yml , и доступно множество вариантов конфигурации.

# .yarnrc.yml
YarnPath: .yarn/releases/yarn-3.1.1.cjs

yarn berry может использовать метод импорта $> yarn plugin import <name> чтобы расширить плагин (yarnpkg.com/cli/plugin/…), эта команда будет также обновите .yarnrc.yml .

# .yarnrc.yml
плагины:
  - путь: .yarn/plugins/@yarnpkg/plugin-semver-up.cjs
    спецификация: «https://raw.githubusercontent.com/tophat/yarn-plugin-semver-up/master/bundles/%40yarnpkg/plugin-semver-up.js».

Как упоминалось в разделе истории, по причинам совместимости, Могут возникнуть некоторые проблемы с зависимостями в строгом режиме PnP. Существует типичное решение проблемы PnP такого типа: политика настройки расширения пакетов.

# .yarnrc.yml
Расширения пакета:
  "styled-компоненты@*":
    зависимости:
      response-is: "*"

pnpm

pnpm использует тот же механизм настройки, что и npm , поэтому вы можете использовать файлы .npmrc . Настройка частного реестра работает так же, как и использование npm . Проекты с несколькими пакетами можно поддерживать с помощью функции рабочей области pnpm. Чтобы инициализировать monorepo , необходимо указать расположение пакета в файле pnpm-workspace.yaml .

# pnpm-workspace.yaml
пакеты:
  - 'packages/**'

Монорепо

Что такое Монорепо

(На самом деле здесь есть три концепции: одно хранилище и несколько проектов, одно хранилище и один проект и несколько хранилищ и несколько проектов).

monorepo — это репозиторий, содержащий несколько проектов. Эти проекты называются workspace или пакетами. Хранение всего в одном месте вместо использования нескольких репозиториев — это стратегия организации проекта.

Конечно, это вносит дополнительную сложность. Yarn Classic был первым, кто включил эту функцию, но теперь каждый крупный менеджер пакетов предлагает функциональность рабочей области. В этом разделе показано, как настроить рабочее пространство с помощью каждого из различных менеджеров пакетов.

npm

Команда npm выпустила долгожданную функцию рабочего пространства npm в версии 7. Он содержит множество команд CLI, помогающих управлять многопакетными проектами из корневого пакета. Большинство команд можно использовать с параметрами, связанными с workspace чтобы сообщить npm , следует ли запускать его для определенного, нескольких или всех рабочих пространств.

# Установка всех зависимостей для всех рабочих областей
$ npm я --workspaces.
# запускаем один пакет
$ npm запустить тест --workspace=hooks
# запуск нескольких пакетов
$ npm запустить тест --workspace=hooks --workspace=utils
# беги против всех
$ npm запустить тест --workspaces
#игнорировать все пакеты, отсутствующие в тесте
$ npm run test --workspaces --if-present

советы: по сравнению с другими менеджерами пакетов npm v8 в настоящее время не поддерживает расширенную фильтрацию или параллельное выполнение нескольких команд, связанных с рабочей областью.

Yarn

В августе 2017 года команда Yarn объявила о поддержке monorepo для функциональности рабочей области. Раньше менеджеры пакетов можно было использовать только в проектах с несколькими пакетами со сторонним программным обеспечением, таким как Lerna. Это новое дополнение к Yarn также открывает возможность другим менеджерам пакетов реализовать такую ​​функциональность.

Если вам интересно, вы можете узнать, как использовать функцию рабочего пространства Yarn Classic с Lerna и без нее. Но в этой статье будут представлены только некоторые необходимые команды, которые помогут вам управлять зависимостями в настройке рабочего пространства Yarn Classic .

# Установите все зависимости $yarn для всех рабочих областей 
# Показать дерево зависимостей $ информация о рабочих пространствах пряжи 
# Запустите другой пакет, чтобы запустить $ Yarn Workspace Awesome — запуск пакета
  # Добавляем Webpack в пакет $ Yarn Workspace Awesome - package add - D webpack
  # add React для всех пакетов $ Yarn add React -W

Yarn berry

Yarn Berry с самого начала использовал рабочие пространства, поскольку его реализация построена на концепциях Yarn Classic . В комментарии Reddit ведущий разработчик Yarn Berry представил краткий обзор функций, ориентированных на рабочие пространства, в том числе:

• $ Yarn add --interactive: можно повторно использовать версии из других рабочих пространств при установке пакетов
• $ Yarn up: обновляет все рабочие пространства. Пакет
• $yarn Workspaces фокус: Установите зависимости только для одного рабочего пространства.
• $yarn Workspaces foreach: запустите команду во всех рабочих пространствах.

Yarn Berry использует ряд протоколов, которые можно использовать в поле dependencies или devDependencies файла package.json . Среди них протокол workspace .

В отличие от рабочей области Yarn Classic , Yarn Berry четко определяет, что зависимость должна быть одним из пакетов в этом monorepo . В противном случае, если версии не совпадают, Yarn Berry может попытаться получить свою версию из удаленного реестра.

{
  // ...
  "зависимости": {
    "@doppelmutzi/hooks": "рабочая область:*",
    "http-сервер": "14.0.0",
    // ...
  }  
}

pnpm

Через протокол workspace pnpm внес свой вклад в проект monorepo , аналогичный Yarn Berry . Многие команды pnpm принимают параметры --recursive (-r) или --filter, которые особенно полезны в контексте monorepo . Его собственные команды фильтрации также являются отличным дополнением к Lerna .

# обрезаем все рабочие области  
pnpm -r exec -- rm -rf node_modules && rm pnpm-lock.yaml  
# запускаем все тесты для всех рабочих пространств с областью действия @doppelmutzi
pnpm рекурсивный тест запуска --filter @doppelmutzi/`

Производительность и эффективность диска

Производительность является ключевой частью решения о выборе. В этом разделе представлены тесты, основанные на малых и средних проектах. Вот некоторые примечания к примеру проекта:

• Ни один из наборов тестов не использует функцию рабочей области.
• В небольших проектах указано 33 зависимости.
• В средних проектах указано 44 зависимости.

Я измерил каждый из вариантов нашего менеджера пакетов один раз, используя три варианта использования (UC). Для получения подробной оценки и объяснений просмотрите результаты Проекта 1 (P1) и Проекта 2 (P2).

• UC 1: нет кэша/хранилища, нет файла блокировки, нет node_modules или .pnp.cjs
• UC 2: присутствует кэш/хранилище, нет файла блокировки, нет node_modules или .pnp.cjs
• UC 3: присутствует кэш/хранилище, присутствует файл блокировки, Без node_modules или .pnp.cjs

я использовал инструмент gnomon для измерения времени, затраченного на установку ( yarn | gnomon ). Дополнительно я измерил размер сгенерированных файлов $ du -sh node_modules .

безопасно

НПМ

npm слишком снисходителен к обработке плохих пакетов и обнаружил некоторые уязвимости безопасности, которые напрямую повлияли на многие проекты. Например, в версии 5.7.0 при выполнении команды sudo npm в операционной системе Linux вы можете изменить владельца системных файлов, что сделает операционную систему непригодной для использования.

Еще один инцидент произошел в 2018 году, связанный с кражей биткойнов. В пакет Node.js EventStream добавлена ​​вредоносная зависимость в версии 3.3.6. Этот вредоносный пакет содержит криптографический метод, который пытается украсть биткойны с машины разработчика.

Чтобы решить эти проблемы, новые версии npm используют криптографические алгоритмы для проверки целостности установленных пакетов. ША-512.

Yarn

Yarn Classic и Yarn Berry используют контрольные суммы для проверки целостности каждой упаковки с самого начала. Yarn также пытается помешать вам получить вредоносные пакеты, которые не объявлены в package.json : если обнаружено несоответствие, установка прерывается.

Yarn Berry в режиме PnP не имеет проблем с безопасностью традиционного метода node_modules . По сравнению с Yarn Classic , Yarn Berry повышает безопасность выполнения команд. Вы можете выполнять только пакеты, объявленные в package.json . Эта функция безопасности аналогична pnpm , которую я описываю ниже.

pnpm

pnpm по-прежнему использует контрольные суммы для проверки целостности каждого установленного пакета перед выполнением его кода.

Как мы упоминали выше, и у npm , и Yarn Classic возникли проблемы с безопасностью из-за продвижения. pnpm избегает этой ситуации, поскольку его модель управления не использует повышение прав, а создает вложенные папки node_modules , тем самым устраняя риск несанкционированного доступа к зависимостям. Это означает, что зависимости объявлены в .package.json .

Как мы уже говорили, это особенно важно в условиях monorepo , поскольку алгоритмы повышения иногда могут привести к недетерминизму зависимостей.

Популярное использование проекта

в заключение

Есть действительно большие различия в принципах различных менеджеров пакетов.

Первоначально pnpm выглядит как npm в том смысле, что их pnpm CLI похоже, но управление зависимостями очень отличается; Yarn Classic по -прежнему популярна, но в ближайшем будущем можно отбросить устаревшее программное обеспечение, и поддержка может быть отброшена. Yarn Berry PnP является совершенно новой, но его потенциал революционизировать мир менеджера пакетов еще раз еще не реализован.

За эти годы многие пользователи спрашивали, кто использует, какие менеджеры пакетов, и в целом люди, похоже, особенно заинтересованы в зрелости и принятии Yarn Berry PnP .

Цель этой статьи - предоставить вам несколько перспектив, чтобы решить, какой менеджер пакетов использовать для себя. Я хотел бы отметить, что я не рекомендую конкретный менеджер пакетов. Это зависит от того, как вы взвешиваете различные требования - так что вы все еще можете выбрать все, что вам нравится!

Английский оригинальный адрес: https://blog.logrocket.com/javascript-package-managers-compared/