Следите за зависимостями

Однажды обратил внимание, что у коллег размер проекта (the initial size of the app) перевалил за 10 Мб. Пятничным вечером, когда было скучно, решил посмотреть, в чём там дело, можно ли сделать что-то ощутимое небольшими усилиями.

В проекте практически нет медиафайлов, поэтому сразу смотрим на скрипты и видим монстра под названием vendor.js, который весит 9550 Кб, всё остальное значительно меньше. Для анализа содержимого воспользуемся инструментом webpack-bundle-analyzer.

dependencies

Обнаружил, что пакет xlsx используется дважды. Идём в package-lock.json. Один пакет используется самим проектом, указан в package.json, версия у него 0.16.3. Второй пакет является зависимостью xlsx-parse-json с версией 0.14.5. Что интересно, так это то, что у xlsx-parse-json в зависимостях указан xlsx версии ^0.14.1, то есть его должна была устроить имеющаяся версия 0.16.3.

Первой мыслью является вариант с порядком установки: сначала была установлена наша внутренняя библиотека, которая и принесла xlsx-parse-json, а потом разработчики на проекте уже отдельно установили более новую версию xlsx. Но попытки установить это в «нужном» порядке ни к чему не привели. Попытался посмотреть, что будет, если понизить минорную версию. Установил xlsx 0.14.3, затем нашу библиотеку, тянущую xlsx-parse-json, которому, напоминаю, нужен xlsx ^0.14.1. Но нет, не устроил его имеющийся в node_modules пакет, и  он аналогично установил себе версию 0.14.5.

Хотел было предложить автору xlsx-parse-json перенести xlsx из dependencies в peerDependencies, вот только на Гитхабе он не был уже более полугода. А может, форкнуть проект? Смотрю, а весь код состоит из одного небольшого js-файла. Так рождается решение.

  1. Копируем этот файл себе в библиотеку, в сервисы.
  2. Переименовываем, меняем разрешение с js на ts, линтим.
  3. Создаём класс с нужным публичным методом, добавляем @Injectable (у нас Ангуляр).
  4. В package.json в зависимостях меняем xlsx-parse-json на xlsx.
  5. В другом сервисе, который раньше использовал xlsx-parse-json, при помощи DI используем выше созданный класс.
  6. Всё это в обязательном порядке проверяется на работоспособность, включая сравнение с тем, как это работало до момента, когда начали трогать код.

Итак, готова новая версия внутренней библиотеки, которая использует xlsx, отдаём её нашему пациенту, который тоже использует xlsx, смотрим на состояние. Анализируем package-lock.json (или используем webpack-bundle-analyzer), видим, что теперь этот пакет установлен в одном экземпляре.

Исходный размер проекта сократился более, чем на 10%, с 10,59 Мб до 9,37 Мб.

Вывод простой: всегда следите за тем, что происходит с вашим проектом при добавлении любой зависимости, можно ли обойтись без неё, какие есть аналоги и т. д. И необязательно делать это вручную, при желании подобный монтирониг легко автоматизировать.

{{ message }}

{{ 'Comments are closed.' | trans }}