Yarn — менеджер пакетов для ноды — выпустили вторую версию. И, похоже, парни серьёзно вознамерились изменить статус-кво в экосистеме ноды, а то и вообще в пакетных менеджерах. Удаляйте все свои картинки про гигабайтные мамки node_modules, убирайте yarn install из скриптов CI, мы начинаем очередную великую JavaScript-смуту. Если вкратце:

• Режим Plug'n'Play стал дефолтным, а node_modules — вторичным, через плагин.
• Сделали плагин и воркфлоу для монореп — может и lerna будет не нужна.
• Встроили свой мини-шелл, чтобы скрипты пакета без этих ваших cross-env в винде запускать.
• Добавили пролог для проверки правил между воркспейсами.
• npx опять же свой запилили.

Если вы не хотите обновлять все ваши проекты, просто запустите yarn policies set-version ^1 (смотри legacy.yarnpkg.com/en/docs/cli/policies) в репозиториях, которые должны остаться на Yarn 1 и закомитьте результат. Тогда Yarn будет использовать локальные бинарники Yarn 1 вместо глобальных так что все в команде будут использовать одну версию!

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

По поводу первого пункта yarn загонялся всегда — собственно, это и было причиной по которой он когда-то появился, мигом потеснив npm (напомню, тогда запуск npm install мог давать разные результаты, потому что lock-файл в мире ноды — это заслуга yarn). Хотя лично я перешёл на него из-за бесящей строчки в логах npm.

Но теперь они решили, так сказать, пушнуть до лимита. При добавлении пакета он (и все его зависимости), в виде zip архива добавляется в кеш, в папку .yarn в папке пакета (как .git). Вместо node_modules создаётся файлик .pnp.js, который и обрабатывает импорты модулей. Важных следствия два:

1. Можно добавлять этот кеш напрямую в гит — и тогда после чекаута у вас сразу будет актуальная версия приложения со всеми зависимостями.
2. Гораздо лучше работает yarn link — теперь корректно обрабатываются и peer dependencies

По поводу платформы же — парни перешли на архитектуру плагинов (то есть yarn в первую очередь как API, а уже потом как CLI) и даже заявляли что хотят отвязаться от ноды как таковой, сделав yarn generic-решением для выстраивания собственных менеджеров пакетов.

Звучит интересно, амбициозно и слегка самоуверенно. Посмотрим, справятся ли они или заглохнут уже на этапе PnP-first.

Во всяком случае, я попробую перевести наш проект на yarn 2, если получится — это будет приятно. Вы как?

UPD: Про пролог в заголовке — это не шутка, на нём можно будет писать правила проверки воркспейсов, next.yarnpkg.com/features/constraints

Далее — выжимка из официального анонса.

Самое важное

Вывод в консоль переделан для лучшей читаемости
Команды CLI (yarn add, ...) теперь учитывают воркспейсы
Можно избавиться от yarn install внутри своего репозитория
Менее опасная альтернатива npx: yarn dlx, чтобы запускать одноразовые штуки
Запуск команды на всех воркспейсах с yarn workspaces foreach
Манкипатчинг пакетов через протокол patch:
Ссылки на локальные пакеты через протокол portal:
Новый воркфлоу чтобы нормально релизить воркспейсы
Декларативная проверка и фиксы воркспейсов (PROLOG INCLUDED)

А ещё...

Пакеты билдятся только если без этого совсем уж никак
Билды пакетов могут быть включены/выключены
Скрипты выполняются в универсальном шелле
Peer dependencies работают даже через yarn link
Локфайл стал обычным YAML
Весь код теперь на TypeScript
Поддержка плагинов

Breaking changes

Настройки стали единообразными
Пакеты должны соблюдать свои границы
Bundle dependencies больше не поддерживаются
Пакеты хранятся в read-only архивах

Детальный чейнджлог здесь, инструкции по обновлению — здесь.

Сложно будет переехать на Yarn 2?

Спасибо нашим бета-тестерам и общей поддержке экосистемы, мы облегчили кучу боли, связанной с таким массивным обновлением. Руководство по переезду расскажет детальней, но в целом пока вы используете последние версии инструментов (ESLint, Babel, TypeScript, Gatsby, и т.д.), всё должно быть норм.

Но есть один значимый косяк: Flow и React-Native сейчас нельзя использовать с Plug’n’Play (PnP). Мы ищем пути сотрудничества с их командами чтобы всё заработало. Сейчас же вы можете оставаться на Yarn 1 или использовать плагин node_modules, который предоставляет обратную совместимость для облегчения перехода (он всё ещё в работе, могут быть баги). Больше — здесь.

Что будет со старой версией?

Yarn 1.22 зарелизится на следующей неделе. После это ветка 1.x официально войдёт в режим доживания — то есть, не будет никаких релизов, кроме фиксов уязвимостей. Новые фичи будут делаться исключительно в Yarn 2. На практике это означает:

• Старый репозиторий (yarnpkg/yarn) уедет в yarnpkg/legacy чтобы отразить его статус доживания. Он будет открыт какое-то время, но скорее всего мы архивируем его через год или два.
• Новый репозиторий не будет переименован в yarnpkg/yarn, так как это поломает множество старых ссылок. В обозримом будущем он останется на yarnpkg/berry.
• Старый сайт уедёт на legacy.yarnpkg.com, новый сайт (сейчас — next.yarnpkg.com) переедет на главный домен yarnpkg.com
• Пакет yarn на npm будет обновляться так:
  
  
  • Тег berry будет всегда показывать на последний релиз 2.x
  • Тег legacy всегда будет показывать на последний релиз 1.x
  • Тег latest будет показывать на legacy несколько недель, а потом переключится на berry. Это нужно чтобы дать всем время закрепить старую версию, если их приложения несовместимы с Yarn 2.
• Докер-образ Node скорее всего будет идти с Yarn 2 начиная с Node 14, примерно в апреле 2020 года. До тех пор вы можете спокойно использовать yarnPath чтобы прозрачно использовать Yarn 2 на всех образах ноды с небольшими изменениями в конфигурации.
• Мы переходим на полностью автоматические GitHub Actions и некоторые пакетные репозитории (в частности Homebrew, Chocolatey и т.д.) ещё не прикручены. В итоге они получат апдейт Yarn 2 позже чем остальные. Рекомендуем использовать yarn set version (или yarn policies set-version на Yarn 1).
  

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