Казалось бы что может быть проще и банальнее, чем обновить зависимости во фронтенд-проекте? Но зачастую даже опытные мидлы делают это не правильно и ставят себе палки в колеса. Давайте разберемся почему так происходит и как этого избежать.

Как обычно происходит обновление?

Типичный сценарий выглядит так:

  1. Обновляем зависимости в package.json.

  2. Чиним то, что сломалось.

Что здесь не так? На первом этапе мы не знаем, сколько времени уйдет на устранение багов, которые могут появиться после обновления. Если проект свежий, с минимумом легаси, и мы просто ставим минорную версию — скорее всего, всё пройдет гладко. Но что, если нужно обновить React с версии 16 до 18? Ох, сколько же всего может пойти не так.

Как обновлять зависимости без боли

Я рекомендую придерживаться следующего порядка:

  1. Прочитайте changelog пакетов, которые мы будем обновлять, а также руководства по миграции (migration guide).

  2. Обновите зависимости в package.json.

  3. Обновите части проекта проекта, которые не будут работать на основе информации из пункта 1.

  4. Протестируйте проект и почините остальное.

  5. По возможности — удалите 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, сборщик и т.п. Перед каждым этапом читаем чейнджлог и гайды по миграции, потом адаптируем код. Затем тестируем проект. Такой подход позволяет избежать резких изменений и сохраняет контроль над ситуацией.

В завершение

Пожалуйста, не обновляйте зависимости вслепую. Даже если "всё работает", спустя месяц может выясниться, что баг всё-таки был. А ведь его можно было бы избежать, просто потратив пару минут на чтение чейнджлога библиотеки.

Обновляйтесь осознанно — и всё будет хорошо.