Автор этой статьи сравнивает различия между текущими основными инструментами управления пакетами npm, yarn и pnpm и предлагает соответствующие предложения по использованию.
NPM
npm — одна из главных причин успеха Node.js. Команда npm проделала большую работу, чтобы обеспечить обратную совместимость и согласованность npm во всех средах.
нпм построен вокругСемантическое управление версиями (semver)разработан с учетом этой идеи, следующая выдержка из их веб-сайта:
Учитывая номер версии: основной номер версии, дополнительный номер версии, номер версии патча, в следующих трех случаях необходимо увеличить соответствующий номер версии:
- Номер основной версии: при изменении API он несовместим с предыдущей версией.
- Дополнительный номер версии: когда функциональность добавлена, но совместима с предыдущими версиями.
- Номер версии исправления: когда исправлены ошибки, совместимые с предыдущими версиями.
npm использует файл с именем package.json, в котором пользователь может сохранить все зависимости в проекте с помощью команды npm install --save.
Например, запуск npm install --save lodash добавит следующие строки в файл package.json.
"dependencies": {
"lodash": "^4.17.4"
}
Обратите внимание, что перед номером версии lodash стоит символ ^. Этот символ указывает npm установить любую версию с основной версией, равной 4. Поэтому, если я запущу npm для установки сейчас, npm установит последнюю версию lodash с основной версией 4, вероятно, lodash@4.25.5 (@ — это указанная версия соглашения npm, используемого для определения имен пакетов). Вы можете увидеть все поддерживаемые символы здесь:docs.npmjs.com/misc/semver.
Теоретически незначительное изменение номера версии не влияет на обратную совместимость. Поэтому установка последней версии библиотеки зависимостей должна работать и содержать важные исправления ошибок и безопасности, начиная с версии 4.17.4.
Однако, с другой стороны, даже если разные разработчики используют один и тот же файл package.json, у них могут быть разные версии одной и той же библиотеки, установленные на их собственных компьютерах, с потенциально трудными для отладки ошибками и "На моем компьютере... "ситуация.
Большинство библиотек npm сильно зависят от других библиотек npm, что может привести к вложенным зависимостям и увеличить вероятность несоответствия соответствующей версии.
Хотя поведение по умолчанию с использованием ^ перед номером версии можно отключить с помощью команды npm config set save-exact true, это влияет только на зависимости верхнего уровня. Поскольку каждая зависимая библиотека имеет свой собственный файл package.json и может иметь знак ^ перед своими собственными зависимостями, невозможно предоставить гарантии содержимого вложенных зависимостей через файл package.json.
Чтобы решить эту проблему, npm предоставляетshrinkwrapЗаказ. Эта команда создаст файл npm-shrinkwrap.json, в котором будут записаны точные версии всех библиотек и всех вложенных зависимостей.
Однако даже если файл npm-shrinkwrap.json существует, npm заблокирует только версию библиотеки, а не содержимое библиотеки. Несмотря на то, что npm теперь не позволяет пользователям повторно публиковать одну и ту же версию библиотеки несколько раз, администраторы npm по-прежнему могут принудительно обновлять определенные библиотеки.
Вот что цитируется из документации по термоусадочной пленке:
Если вы хотите заблокировать определенные байты в пакете, например, чтобы обеспечить правильное повторное развертывание или сборку, вам следует проверить зависимости в системе управления версиями или использовать какой-либо другой механизм для проверки содержимого вместо проверки тестовой версии содержимого.
npm 2 устанавливает все зависимости, от которых зависит каждый пакет. Если у нас есть проект, который зависит от проекта A, проект A зависит от проекта B, а проект B зависит от проекта C, то дерево зависимостей будет выглядеть так:
node_modules
- package-A
-- node_modules
--- package-B
----- node_modules
------ package-C
-------- some-really-really-really-long-file-name-in-package-c.js
Эта структура может быть очень длинной. Это не более чем небольшая неприятность для операционных систем на основе Unix, но разрушительная вещь для Windows, поскольку существует множество программ, которые не могут обрабатывать пути к файлам длиннее 260 символов.
npm 3 решает эту проблему с помощью плоского дерева зависимостей, поэтому наша структура из 3 проектов теперь выглядит так:
node_modules
- package-A
- package-B
- package-C
-- some-file-name-in-package-c.js
Таким образом, изначально длинное имя пути к файлу изменяется с ./node_modules/package-A/node_modules/package-B/node-modules/some-file-name-in-package-c.js на /node_modules/some - имя-файла-в-пакете-c.js.
ты сможешьздесьУзнайте больше о том, как работает разрешение зависимостей NPM 3.
Недостатком этого подхода является то, что npm должен сначала просмотреть все зависимости проекта, прежде чем решить, как сгенерировать плоскую структуру каталогов node_modules. npm должен построить полное дерево зависимостей для всех используемых модулей, что является трудоемкой операцией иОчень важная причина низкой скорости установки npm.
Поскольку я не знал подробностей об изменениях npm, я предположил, что каждый раз, когда я запускал команду установки npm, NPM приходилось загружать все из Интернета.
Однако я ошибался, у npm есть локальный кеш, в котором сохраняется tar-архив каждой скачанной версии. Содержимое локального кэша можно просмотреть с помощью команды npm cache ls. Локальный кэш предназначен для сокращения времени установки.
В целом, npm — зрелый, стабильный и интересный менеджер пакетов.
Yarn
Yarn был выпущен в октябре 2016 года и быстро набрал 24 000 звезд на Github. А у npm всего 12 000 звезд. Этот проект поддерживается несколькими старшими разработчиками, в том числе Себастьяном Маккензи (Babel.js) и Иегуда Кац (Ember.js,Rust,BundlerЖдать).
Из того, что я понял, основная цель Yarn в начале состояла в том, чтобы устранить двусмысленность установки npm из-за семантического управления версиями, описанного в предыдущем разделе. Хотя можно использовать npm shrinkwrap для создания предсказуемого дерева зависимостей, это не вариант по умолчанию, и все разработчики должны знать и включать этот параметр.
У пряжи был другой подход. При каждой установке пряжи создается файл yarn.lock, аналогичный npm-shrinkwrap.json, и он создается по умолчанию. В дополнение к общей информации, файл yarn.lock также содержит контрольные суммы того, что нужно установить, чтобы убедиться, что используются одни и те же версии библиотек.
Поскольку yarn — это новый переработанный клиент npm, он позволяет разработчикам распараллеливать все необходимые операции и добавляет несколько других улучшений, что приводит к значительному ускорению времени выполнения и общего времени установки. По моему мнению, повышение скорости является основной причиной популярности пряжи.
Как и npm, yarn использует локальный кеш. В отличие от npm, yarn не требует подключения к Интернету для установки локально кэшированных зависимостей, он обеспечивает автономный режим. Эта функция была предложена в проекте npm в 2012 году, но так и не была реализована.
Yarn также предлагает некоторые другие улучшения, например, он позволяет объединять лицензии всех пакетов, используемых в проекте, что приятно.
Интересно, что отношение документации пряжи к npm начало меняться по мере того, как проект пряжи становился популярным.
Первоначальное объявление о пряже описывало установку пряжи следующим образом:
*Самый простой способ начать — запустить:
npm install -g yarn
yarn*
Текущая страница установки пряжи говорит следующее:
Примечание. Установка через npm обычно не рекомендуется. Установки npm недетерминированы, пакеты не подписаны, и npm не выполняет никаких проверок целостности, кроме базового хэширования SHA1, что представляет угрозу безопасности для установки системных программ.
По этим причинам настоятельно рекомендуется устанавливать пряжу с помощью метода установки, наиболее подходящего для вашей операционной системы.
При таких темпах мы не удивимся, если пряжа объявит о своем собственном реестре и позволит разработчикам постепенно отказываться от npm.
Кажется, благодаря пряже npm наконец осознает, что им нужно уделять больше внимания некоторым вопросам, о которых спрашивают люди. Когда я просматривал крайне востребованную «автономную» функцию, о которой я упоминал ранее, я заметил, что это требование активно исправляется.
pnpm
Как я упоминал, вpnpmАвтор Золтан Кочан разместил "Зачем использовать пнпм?«После этого я узнал о pnpm.
Я не буду вдаваться в подробности (поскольку этот пост был давно), но вы можете проверить мойоригинальный постчтобы найти больше контента иПрисоединяйтесь к обсуждению в Twitter.
но
Я хотел бы отметить, что pnpm работает очень быстро, дажеПревышает npm и пряжу.
Почему так быстро? Потому что он использует умный подход, используя жесткие и символические ссылки, чтобы избежать копирования всех локально кэшированных исходных файлов, что является одним из самых больших недостатков производительности пряжи.
Использование ссылок — дело непростое, и возникает множество вопросов, которые необходимо учитывать.
как СебастьянTwitterКак указывалось выше, изначально он намеревался использовать символические ссылки в пряже, но из-за другихнекоторые причиныбросил его.
В то же время, как и более 2000 звезд на Github, pnpm может использоваться многими людьми.
Кроме того, по состоянию на март 2017 года он наследует все преимущества пряжи, включая автономный режим и детерминированную установку.
Суммировать
Я думаю, что разработчики пряжи и pnpm проделали потрясающую работу. Лично мне нравится детерминированная установка, потому что я люблю контроль и не люблю сюрпризов.
Каким бы ни был результат этого конкурса, я благодарен, что пряжа зажгла огонь под ногами npm, предложив альтернативу.
Я уверен, что yarn — более безопасный вариант, но pnpm может быть лучшим вариантом для некоторых тестовых случаев. Например, это может быть полезно в малых и средних командах, которые выполняют множество интеграционных тестов и хотят установить зависимости как можно быстрее.
В конце концов, на мой взгляд, npm по-прежнему предоставляет очень полезное решение, поддерживающее большое количество тестовых случаев. Большинство разработчиков по-прежнему могут работать с исходным клиентом npm.
Больше ссылок на РН
Плюсы и минусы реактивной технологии
Несколько проектов с открытым исходным кодом, которые необходимо увидеть при изучении React Native