Yarn — новинка в мире управления пакетами Javascript и Node.js. Я вижу, как некоторые разработчики переходят от npm
к yarn
, в то время как некоторые другие все еще колеблются. Я был в более поздней группе, но следующие 3 фактора заставили меня принять решение о переходе.
1. Насколько легко перейти с NPM на Yarn
Я обнаружил, что большинство проектов, над которыми я работаю, совместимы с yarn
, и в документах о перенастройке пряжи утверждается то же самое. Установить пряжу и преобразовать существующий проект было так же просто:
# Install yarn globally with your existing npm installation $ npm install -g yarn # Remove existing npm dependencies and clean the cache $ rm -rf node_modules $ npm cache clean # Run yarn $ yarn
Поскольку yarn
использует тот же npm, что и package.json
, миграция существующего списка зависимостей — довольно приятный процесс.
2. Последовательность и простота в управлении зависимостями
При работе над более крупными проектами с большей командой управление зависимостями и их версиями часто становится затруднительным. Вы столкнетесь с ситуациями, когда разработчики пропускают синхронизацию или блокировку зависимостей с помощью npm shrinkwrap. Практика проверки зависимостей в качестве каталога поставщика для системы управления версиями также невозможна с npm, поскольку npm устанавливает зависимости в node_modules
недетерминированным образом, что вызывает проблему работает на моей машине. Фактически, в сообщении в блоге, посвященном Yarn, разработчики объясняют аналогичные ситуации в Facebook, которые привели к разработке Yarn.
Yarn решает эти проблемы, добавляя файл yarn.lock
, который генерируется при запуске yarn
, и сглаживая файловую структуру зависимостей с помощью детерминированного алгоритма, который устанавливает одинаковые зависимости везде, где вы запускаете yarn.
3. Скорость в масштабе
Количество времени, которое вы экономите на конвейерах непрерывной интеграции и производственной сборки, имеет наибольшее значение при развертывании несколько раз в день. Вы можете увидеть огромную разницу, когда проект имеет большее количество зависимостей. Я попытался протестировать проект с более чем 40 зависимостями.
Установка НПМ:
# Prep for test # Removed existing dependencies and npm cache $ rm -rf node_modules $ npm cache clean $ time npm install
Время npm install
заняло в среднем. пробег длился 1:29:24 минуты
Установка пряжи:
# Prep for test # Removed existing dependencies $ rm -rf node_modules $ time yarn
Среднее время, затраченное на yarn
, составило впечатляющие 10:70 сек!
Yarn следует подходу сохранения каталога глобального кеша, поэтому после загрузки пряжа может получать зависимости в автономном режиме, связывая зависимости из глобального кеша с локальным каталогом node_modules
.
Вывод
Сейчас Yarn движется в правильном направлении, решая дилеммы управления пакетами в экосистеме Javascript и Node.js. В настоящее время Yarn поддерживает реестры npm и bower. Я с нетерпением жду поддержки частного реестра и надеюсь, что yarn будет двигаться вперед в направлении децентрализации подхода к реестру, аналогичного экосистеме Go. Yarn уже поддерживает извлечение зависимостей, хранящихся в виде tarball-файлов, для полного рабочего процесса в автономном режиме, а также поддержку извлечения зависимостей в виде удаленных URL-адресов git.
— Джинматт