Обновление зависимостей

Kepler.gl построен как надстройка над экосистемой React, Redux и deck.gl, поэтому обновления зависимостей в этом проекте почти всегда затрагивают не одну библиотеку, а целый стек.

Ключевые группы зависимостей:

  • UI-слой: React, react-dom, styled-components (в некоторых версиях)
  • Состояние: Redux, react-redux, redux-thunk
  • Визуализация: deck.gl, luma.gl, @deck.gl/* пакеты
  • Гео- и дата-утилиты: d3-подобные утилиты, turf.js
  • Сборка: webpack, babel, terser
  • Внутренние пакеты Uber/Vis.gl: shared-utils, constants, schema-manager

Особенность архитектуры заключается в жесткой связке версий deck.gl и luma.gl. Несовпадение minor-версий часто приводит к runtime-ошибкам WebGL-слоя или некорректной отрисовке слоев карты.


Семантика версий и точки риска

При обновлении зависимостей в Kepler.gl важно учитывать, что проект опирается не только на SemVer, но и на фактическую совместимость пакетов внутри визуализационного ядра.

Критические зоны несовместимости:

  • deck.gl ↔︎ luma.gl
  • React ↔︎ react-redux
  • webpack ↔︎ babel-loader
  • TypeScript typings ↔︎ фактические runtime API (если используются типы поверх JS)

Типичная проблема возникает при обновлении deck.gl на новую major-версию без синхронного обновления всех @deck.gl пакетов. Даже при успешной сборке поведение слоев (ArcLayer, HexagonLayer, ScatterplotLayer) может измениться из-за переработанных shader-абстракций.


Проверка текущего дерева зависимостей

Перед обновлением выполняется анализ установленного графа зависимостей:

npm ls deck.gl
npm ls react
npm ls redux

или при использовании yarn:

yarn why deck.gl
yarn why react

Особое внимание уделяется дубликатам:

  • multiple versions of deck.gl
  • multiple react-redux instances
  • конфликтующие версии babel runtime

Дублирование приводит к эффекту “двойного контекста”, когда компоненты используют разные инстансы Redux store или WebGL контекста.


Обновление React-слоя

React в Kepler.gl обычно относится к строго ограниченному диапазону версий. При переходе между major-версиями React требуется учитывать:

  • изменение reconciliation алгоритма
  • обновление context API
  • совместимость react-redux connect()

При переходе на React 18 важным становится режим concurrent rendering, который может конфликтовать с некоторыми синхронными обновлениями состояния карты.

Типовые шаги обновления:

  • проверка peerDependencies у react-redux
  • обновление react-dom синхронно с react
  • контроль StrictMode поведения (двойные вызовы lifecycle)

Обновление Redux и состояния приложения

Kepler.gl активно использует глобальное состояние для управления слоями карты, фильтрами и датасетами.

При обновлении Redux учитываются:

  • изменения middleware API
  • поведение combineReducers
  • совместимость с redux-thunk или redux-saga (если расширено)

Особенно критично поведение immutability. Любые изменения в reducer-логике могут привести к некорректному пересчету визуальных слоев.

Риски:

  • потеря синхронизации фильтров временных рядов
  • некорректное обновление dataset state
  • race conditions при batch actions

Обновление deck.gl и визуального ядра

deck.gl является центральным компонентом Kepler.gl, отвечающим за WebGL рендеринг слоев.

При обновлениях необходимо учитывать:

  • изменения API Layer классов
  • переработку shader uniforms
  • изменение coordinate system (LNGLAT vs WebMercator)
  • обновление взаимодействия с mapbox-gl

Типичный сценарий миграции:

  1. Проверка версии Kepler.gl, связанной с deck.gl
  2. Сопоставление @deck.gl/* пакетов
  3. Проверка breaking changes в changelog deck.gl
  4. Тестирование каждого слоя отдельно

Особое внимание уделяется:

  • HexagonLayer (агрегация данных)
  • GeoJsonLayer (геометрия)
  • ArcLayer (визуализация связей)

Любое изменение в shader pipeline может визуально исказить карту без явных ошибок в консоли.


Синхронизация luma.gl и WebGL контекста

luma.gl управляет низкоуровневым WebGL доступом. Несовместимость версий часто проявляется в виде:

  • черного canvas вместо карты
  • ошибок контекста WebGL context lost
  • неправильного рендеринга текстур

При обновлении:

  • проверяется соответствие peerDependencies deck.gl
  • очищается node_modules и lockfile при конфликте
  • пересобираются shader зависимости

Работа с lockfile и детерминированностью сборки

Kepler.gl чувствителен к различиям в lockfile из-за большого числа транзитивных зависимостей.

Основные стратегии:

  • npm: package-lock.json фиксируется и не смешивается с yarn.lock
  • yarn: предпочтительно использовать resolutions
  • pnpm: требует careful hoisting настроек

При обновлениях часто применяется последовательность:

  • удаление node_modules
  • очистка lockfile
  • повторная установка зависимостей
  • проверка dedupe результата

Обновление webpack и сборочного пайплайна

Webpack в Kepler.gl управляет:

  • транспиляцией ES модулей
  • сборкой WebGL шейдеров
  • оптимизацией бандла

При обновлении webpack необходимо учитывать:

  • совместимость с babel-loader
  • изменения в tree-shaking
  • поведение code splitting

Типичные проблемы:

  • увеличение bundle size после обновления terser
  • несовместимость старых babel preset-env конфигураций
  • ошибки при dynamic import() для слоев карты

Управление peerDependencies

Kepler.gl активно использует peerDependencies для предотвращения дублирования React и deck.gl.

При обновлении:

  • проверяются warnings npm install
  • сверяются диапазоны версий
  • исключаются автоматические обновления несовместимых пакетов

Игнорирование peerDependencies часто приводит к runtime-конфликтам, которые сложно диагностировать, так как сборка проходит успешно.


Миграция между major-версиями Kepler.gl

Переход между major-версиями Kepler.gl почти всегда требует синхронного обновления:

  • deck.gl
  • react
  • redux
  • mapbox-gl

Типовой порядок миграции:

  • анализ changelog Kepler.gl
  • фиксация текущего состояния приложения
  • обновление зависимостей по одному уровню
  • проверка каждого визуального слоя
  • тестирование загрузки dataset

Критическим этапом является проверка сериализации состояния карты, так как изменения схемы state могут ломать сохраненные конфигурации.


Проверка после обновления зависимостей

После завершения обновления выполняется контроль функциональности:

  • загрузка больших датасетов
  • отрисовка всех типов слоев
  • взаимодействие с фильтрами времени
  • экспорт и импорт конфигурации

Особое внимание уделяется производительности WebGL:

  • FPS при большом количестве точек
  • время инициализации карты
  • потребление памяти GPU

Любое ухудшение часто связано с несовместимостью minor-версий deck.gl или luma.gl, даже если ошибки отсутствуют в консоли.