Казалось бы что может быть проще и банальнее, чем обновить зависимости во фронтенд-проекте? Но зачастую даже опытные мидлы делают это не правильно и ставят себе палки в колеса. Давайте разберемся почему так происходит и как этого избежать.
Как обычно происходит обновление?
Типичный сценарий выглядит так:
Обновляем зависимости в
package.json.Чиним то, что сломалось.
Что здесь не так? На первом этапе мы не знаем, сколько времени уйдет на устранение багов, которые могут появиться после обновления. Если проект свежий, с минимумом легаси, и мы просто ставим минорную версию — скорее всего, всё пройдет гладко. Но что, если нужно обновить React с версии 16 до 18? Ох, сколько же всего может пойти не так.
Как обновлять зависимости без боли
Я рекомендую придерживаться следующего порядка:
Прочитайте changelog пакетов, которые мы будем обновлять, а также руководства по миграции (migration guide).
Обновите зависимости в
package.json.Обновите части проекта проекта, которые не будут работать на основе информации из пункта 1.
Протестируйте проект и почините остальное.
По возможности — удалите deprecated-код.
Большинство популярных библиотек и фреймворков публикуют подробные руководства по миграции при мажорных релизах — будь то React, MobX или Ant Design. Даже просто changelog в корне репозитория может сэкономить кучу времени. Ознакомившись с ним, вы заранее будете знать, что может пойти не так, и сможете подготовиться.
Хорошая практика — сразу избавляться от deprecated кода. Это немного болезненно в моменте, зато в будущем значительно упростит жизнь при следующих обновлениях.
А если у нас "боль и страдание"?
Рассмотрим реальный кейс. Представим, что у нас проект с диким легаси: React 16.6.0, ts-lint вместо ESLint, старые MobX и Webpack и другие зависимости, которые не трогали лет пять. И всё это надо обновить до актуальных версий.
Что делать? Самое разумное — разбить обновление на этапы. Например, React:
16.6.0 → 16.14.0 → 17.0.2 → 18.3.1 → 19.2.0
Параллельно обновляем другие критичные зависимости — MobX, сборщик и т.п. Перед каждым этапом читаем чейнджлог и гайды по миграции, потом адаптируем код. Затем тестируем проект. Такой подход позволяет избежать резких изменений и сохраняет контроль над ситуацией.
В завершение
Пожалуйста, не обновляйте зависимости вслепую. Даже если "всё работает", спустя месяц может выясниться, что баг всё-таки был. А ведь его можно было бы избежать, просто потратив пару минут на чтение чейнджлога библиотеки.
Обновляйтесь осознанно — и всё будет хорошо.