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.

— Джинматт