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

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

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

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

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

17
git javascript version-control yarnpkg

2 ответов

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

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

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

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

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

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

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

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

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

эта команда обновляет зависимости до последней версии на основе диапазона версий, указанного в . The yarn.lock файл также будет воссоздан.

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

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

что я предлагаю вам сделать, это создать скрипт, который будет проверять текущую версию 'рекомендуемый' с помощью:

yarn check

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

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

3) Обновление серверной продукции

аналогично 2 ) используя крючок ЖКТ скрипт, должно помочь вам!--4--> если package.json версия правильна, если не запустить yarn update.

2