Комментарии 2
Допустим, однажды в проекте, который отлично работал (и не менялся), начинает происходить ошибка компиляции из-за обновления прямой (или транзитивной) зависимости. Думаю, большинство разработчиков с этим сталкивались. В первый раз я как опытный джавист, перешел на жесткие версии (в тот раз помогло), но теперь я знаю, что это неправильно.
Вопрос:
1) как в соответствии с изложенным следует поступить? Конкретно какие команды и изменения в package.json, если можно
2) верно ли утверждение, что yarn намного адекватнее и гибче в этом смысле (например, в прибивании жесткой версии пакета, когда это необходимо). Или же в поздних версиях npm эти проблемы устранены
Извиняюсь за капитальную задержку с ответом, не заметил среди уведомлений :)
Стоит заметить, что если Вы используете lock-файл, то сама по себе проблема возникнуть не может. Она может возникнуть только после обновления дерева зависимостей.
Первое что нужно сделать в такой ситуации — попытаться разобраться почему возникла проблема. Скорее всего нужно внести изменения либо в Ваш проект, либо в саму библиотеку. Возможны оба варианта — например делаем фикс у себя и пишем жалобу автору библиотеки.
В качестве временного фикса можно запинить зависимость в package.json. Если зависимость прямая, то это делается прямо в массиве "*dependencies", если транзитивная, то в "overrides". Но это не отменяет действий на предыдущем шаге.
На мой взгляд yarn был актуален достаточно давно, когда он только появился и работал в 3 раза быстрее, чем npm. Сейчас npm решает очень многие задачи. Из альтернатив я предпочитаю pnpm, он эффективнее, более строг и позволяет делать монорепы. Возможно у yarn есть какие-то свои преимущества, но у меня не возникала в этом потребность.
Lock-файлы npm