n1ro°
RU

Текст и данные · Инструкция

yarn set version закрепить версию Yarn в проекте

`yarn set version` закрепляет версию Yarn на уровне проекта, чтобы локальная разработка и CI запускали один и тот же релиз. После команды важно проверить не только `yarn --version`, но и то, где именно Yarn записал фиксацию: в `packageManager` или, при соответствующей конфигурации, через `yarnPath`.

Редакция N1RO · Проверено

Короткий ответ

`yarn set version <version>` фиксирует релиз Yarn для проекта, обычно через поле `packageManager`, а при необходимости — через `yarnPath`.

Как команда влияет на Corepack и yarnPath

Команда предназначена для того, чтобы все разработчики и CI использовали один и тот же релиз Yarn. Yarn обычно записывает выбранный релиз в корневой `packageManager`; `--yarn-path` или существующий `yarnPath` могут привести к сохранению бинарника в проекте. Точная версия воспроизводимее тега `latest`: тег удобен для осознанного обновления, но не как плавающая настройка автоматической сборки.

Совет: Сразу после команды смотрите `git diff`: он показывает, какой механизм фиксации выбрал Yarn для этого проекта.

Порядок действий для Yarn Berry

  1. Шаг 1: Выберите точную версию Yarn, совместимую с проектом и используемой версией Node.js.
  2. Шаг 2: В корне выполните `yarn set version <version>` и проверьте изменения `package.json`, `.yarnrc.yml` и `.yarn`.
  3. Шаг 3: Запустите `yarn --version` через тот же Corepack-механизм, который применяется на машинах команды.
  4. Шаг 4: Закоммитьте изменённые конфигурационные файлы и проверьте версию ещё раз в чистом CI.

Что проверить после yarn set version

  • Выбрана конкретная версия Yarn, а не неявная глобальная установка.
  • Diff показывает ожидаемое изменение `packageManager` и/или `yarnPath`.
  • `yarn --version` из корня проекта возвращает закреплённый релиз после нового запуска shell.
  • CI использует тот же Corepack/проектный механизм, а не собственный глобальный Yarn.
  • В коммит включены все файлы, от которых зависит выбор версии Yarn.

Что проверить в Git после `yarn set version`

Сначала просмотрите diff `package.json` и `.yarnrc.yml`. В обычном Corepack-сценарии проектная версия описывается полем `packageManager`; если проект использует `yarnPath`, в репозитории может появиться или измениться локальный бинарник Yarn. После этого откройте новый shell и повторите `yarn --version` из корня проекта, а затем выполните ту же проверку в CI. Если локально отображается одна версия, а в CI другая, проблема обычно не в самой команде фиксации, а в способе запуска Yarn или в том, что конфигурационные изменения не попали в коммит.

Предупреждение: Глобально установленный Yarn может скрыть ошибку конфигурации; проверяйте проект через тот же путь запуска, что и CI.

Где можно случайно закрепить не ту версию Yarn

Не оставляйте в README инструкцию ставить глобально другую версию Yarn: она будет конфликтовать с проектной фиксацией и давать труднообъяснимые lock-диффы.

Признаки корректно закреплённой версии

Фиксация готова, если свежий checkout проекта воспроизводит ту же версию Yarn без ручной глобальной установки. Проверьте это на чистом окружении или CI: если версия расходится, сначала сравните `packageManager`, `.yarnrc.yml` и способ запуска Corepack. Только после этого имеет смысл разбирать lock-файл или зависимости.

Важно: Результат считается воспроизводимым только после проверки на чистом checkout, а не на давно настроенной машине.

Что учитывать

Не оставляйте в README инструкцию ставить глобально другую версию Yarn: она будет конфликтовать с проектной фиксацией и давать труднообъяснимые lock-диффы.

Источники и проверка

Фактическая часть сверена по первичным источникам (в т.ч. yarn set version). Пример и формулировки — редакция N1RO на 2026-09-23.