Yarn: процедура повторного развертывания зависимостей JavaScript на производственном сервере (использование файла `yarn.lock`)

Question

Я прочитал документацию по Yarn и знаю, что файл lock должен быть передан в VC.См. this , который объясняет на высоком уровне, зачем нужен файл блокировки, и this , в котором перечисляется куча команд без подробного объяснения того, что они на самом деле делают!

Я также прочитал много вопросов о StackOverflow, который спрашивает о том, должен ли файл lock быть передан в VC.

Тем не менее, вся документация и SO потоки, кажется, упускают из виду детали, которые я хочузнать, что является следующим;Какова правильная процедура (правильный набор команд для запуска) для:

1. Обновление файла yarn.lock, когда мне нужно (т.е. в среде разработки, где я хочу получить последние минорные версиии обновите файл lock, чтобы отразить это)
2. Для синхронизации моего файла блокировки с другими разработчиками, чтобы гарантировать, что они разрабатывают / тестируют с точно такими же версиями зависимостей, и
3. Дляобновление / повторная синхронизация каталога node_modules на производственном сервере (т. е. чтобы убедиться, что производственный сервер не работает на другой / неработающей версии зависимых пакетов)

Я спрашиваю частично, потому что вВ прошлом при выполнении git pull на сервере я сталкивался с сообщениями о том, что файл yarn.lock обновлялся независимо от процесса разработки / VC.Насколько я понимаю, этого нельзя допустить.

Answer 1

1. Честно говоря, это вопрос мнения / предпочтения. Я видел несколько стратегий:

   • Использование yarn upgrade
   • Вручную подняв версию в package.json перед запуском yarn

2. Как упомянул Фабиен: используйте yarn check

3. Вы можете использовать автономные зеркала пряжи, где вы помещаете кэши ваших пакетов npm в систему контроля версий. (См. эту среднюю статью)

   Плюс есть много плюсов при использовании yarn --offline:

   • Сборки выполняются быстрее, поскольку вам не нужно извлекать пакеты из реестра npm.
   • Ваши сборки не будут работать, если у вас нет нужных зависимостей.

Answer 2

следующая информация основана на том, что мы ежедневно используем в Orange, возможно, это не единственная истина.

1) Обновление yarn.lock

yarn upgrade [package | package@tag | package@version | @scope/]... [--ignore-engines] [--pattern]

Эта команда обновляет зависимости доих последняя версия основана на диапазоне версий, указанном в файле package.json.Файл yarn.lock также будет воссоздан.

источник: https://yarnpkg.com/en/docs/cli/upgrade

2) Зависимость между разработчиками

Я предлагаю вам создать скрипткоторый проверит текущую «рекомендованную» версию на наличие:

yarn check

Проверяет, что версии зависимостей пакетов в текущем проекте package.json совпадают с версиями в блокировке пряжиfile.

source: https://yarnpkg.com/en/docs/cli/check

3) Обновление сервера производства

То же, что 2) использование скрипта git hook, должно помочь вам yarn check, еслиpackage.json версия верна, если не запускается yarn update.