Целесообразно ли периодически удалять файл yarn.lock, чтобы позволить yarn устанавливать последние версии зависимостей и подзависимостей из диапазонов семверта, указанных в package.json?Тот же вопрос относится к package-lock.json и npm.
Причина, по которой я спрашиваю, заключается в том, что в прошлом я работал над проектом, в котором некоторые зависимости были установлены на очень старые версии.Команда (правильно или неправильно) восприняла это как рискованное изменение, чтобы обновить зависимость, которая была двумя основными версиями текущей версии.Поэтому я хочу поддерживать зависимости в актуальном состоянии и избегать обновлений зависимостей большого взрыва.
Моя команда использует модель ветвления git-flow (https://nvie.com/posts/a-successful-git-branching-model/). Так что мне интересно, подойдет ли она длянам начать новый yarn.lock в нашей ветви разработки после того, как каждый релиз объединяется с основной веткой.
РЕДАКТИРОВАТЬ:
Как указал @str, моя оригинальная формулировка (без изменений выше) было немного противоречивым.
Часть, в которой я был непоследователен, заключалась в том, что я спрашивал о получении самой последней версии в пределах диапазона, но затем я привел пример, где я работал над проектом, которыйЭто были «две основные версии позади».
Действительно, наиболее часто используемые операторы диапазона semver (по моему опыту) не позволят yarn или npm установить версию с основным значением выше, чемверсия в выражении диапазона. Например, если вы используете калькулятор nmm semver в https://semver.npmjs.com/ и вводите пакет lodash и диапазон ^ 2.0.0 этобудет соответствовать только версиям 2.xx.
Тем не менее, можно указать диапазон полуверсии, включающий основные обновления версии.Если вы перейдете к https://semver.npmjs.com/ и введете пакет lodash и диапазон> 2, вы увидите, что этот диапазон соответствует всем версиям 3.xx и всем версиям 4.xx.
В любом случае, вопрос в том, чтоЯ собирался спросить больше о разрешении обновлений зависимостей в целом, чем о конкретном случае их обновления до более новой основной версии.Примером двух основных версий была моя попытка сослаться на ситуацию, когда обновление зависимостей начинает казаться рискованным, поэтому команда начинает откладывать это дальше.
Мне кажется, что это похоже на yarn.lock или пакет-lock.json полезен в краткосрочной перспективе, потому что он делает сборку проекта более согласованной на разных машинах, а также полезен в долгосрочной перспективе, потому что позволяет команде проверить историческую ревизию и построить ее так же, как она была создана, когдаэто было создано.Но я также думаю, что для проекта может быть хорошей идеей периодически снимать блокировку, чтобы все зависимости могли обновляться до последних версий в пределах своих диапазонов.Кто-нибудь получил опыт с такой процедурой, которую можно было бы прокомментировать здесь?Или кто-нибудь может сказать мне убедительную причину, почему это будет плохой идеей?