Дорогая, я уменьшил node_modules! … И улучшили производительность приложения в процессе

Сегодня утро понедельника, и вам нужно создать новый проект. Вы устанавливаете все необходимые пакеты npm, а затем начинаете работать над некоторыми функциями. Рано или поздно вы обнаружите проблему, требующую исключительного программирования, поэтому обратитесь в Google и ищите ответ - возможно, пакет. Вы устанавливаете его и создаете образ производственного пакета. Затем вы смотрите на его размер и ... вот откуда у вас сердечный приступ. «Как я получил node_modules 1 ГБ ?!» - борьба настоящая, и поверьте мне, в TSH мы бывали несколько раз. Но не бойтесь, что-то можно сделать, чтобы уменьшить этот размер! Мы сделали несколько простых шагов, чтобы уменьшить размер node_modules. Просто следуй за мной, пожалуйста…

Наша предыстория node_modules

Не так давно мы работали над этим британским финтех-проектом, в рамках которого нам пришлось перевести систему на микросервисную архитектуру с использованием Node.js. Когда нас познакомили с платформой, мы получили от клиента два требования - она ​​должна быть эффективной и легкой. Производительность не является проблемой для Node.js (если вы случайно не заблокируете цикл событий), однако легковесность может быть проблемой. Начальный образ был 32 МБ, что является очень хорошим результатом, но быстро выяснилось, что настоящая проблема заключается в node_modules.

Вопреки тому, что вы думаете, размер приложения важен в нескольких областях:

  • производительность - легкое приложение, которое работает быстрее, требует меньше ресурсов, поэтому во время разработки оно работает более эффективно.
  • затраты - легкое приложение требует меньше ресурсов, а это означает, что затраты на инфраструктуру снижаются, и вы экономите много денег.

Разработчикам нравится упрощать свою работу, чтобы делать все быстрее, поэтому они включают дополнительные библиотеки. К сожалению, это приводит к увеличению размера всего приложения, которое может очень быстро выйти из-под контроля. Так началось наше приключение с «уменьшением веса» node_modules. Итак, что мы сделали, чтобы уменьшить количество модулей node_modules?

Уменьшите количество зависимостей

Это кажется очевидным, но прежде чем мы перейдем к более инвазивным решениям, возможно, вам стоит подумать об устанавливаемых вами пакетах. Неужели все они вам нужны?

В TSH мы используем такие сайты, как или, чтобы фактически увидеть весь график зависимостей для одного пакета, а затем обсуждаем, если это то, что мы ищем.

Я часто вижу, как люди устанавливают Jest только для простых модульных тестов (около 460+ зависимостей, +/- 60 МБ), когда есть меньшие библиотеки, которые будут делать то же самое (Mocha - 115 зависимостей, 12 МБ). Я знаю, о чем вы думаете - это просто зависимость от разработчиков. Да, но, уменьшая количество модулей, вы также ускоряете свою машину разработки. Меньше вещей хранится в памяти, меньше библиотек, которым должна следовать IDE, все это заставляет нас развиваться быстрее. Все сводится к простым аргументам и минусам. В нашем случае мы начали с 700 МБ зависимостей, а после нескольких обменов и удалений у нас осталось всего 256 МБ.

Использовать производственный флаг

Другой очевидный (но иногда забываемый) метод - это использование флага `-production` при установке npm. Он пропустит все devDependencies и будет использовать только производственные. Поверьте, оно того стоит. В большинстве наших проектов размер node_modules уменьшился на + -33% после того, как мы его использовали (176 МБ).

Удалите ненужные файлы

Вы когда-нибудь задумывались о том, что что-то устанавливается, когда вы набираете npm install? Я говорю не обо всем дереве зависимостей, а о большом количестве мусора, который находится внутри. Документы, тесты, уценки, изображения, исходники, множество файлов, которые вообще бесполезны во время разработки (скажите, когда в последний раз вы погружались в node_modules, чтобы читать документы, а?). В TSH мы нашли две классные библиотеки - и. Оба они имеют одну и ту же цель - удалить все, что не нужно для пакета. ModClean имеет три шаблона: безопасный, осторожный и опасный - и иногда удаляет слишком много файлов.

Вот почему мы чаще всего используем node-prune, потому что это не только безопаснее, но и позволяет нам уменьшить node_modules еще на 30% по сравнению с производственной версией.

Для лучшей визуализации: мы начали с 256MB node_modules для dev-версии. После производства мы уменьшили размер примерно до 176 МБ, а затем после удаления узлов - примерно 126 МБ. Это больше половины исходного размера!

Ищи и убирай

Даже после использования node-prune есть кое-что, что можно сделать. В какой-то момент мы начали проверять размер каждого модуля, чтобы увидеть, какие из них самые большие. В случае MacOS и Linux есть очень простая команда:

Он напечатает каждый модуль размером не менее 1 МБ. Сделав это, вы узнаете, какие модули занимают больше всего места. Это было очень полезно, потому что до этого мы не понимали, что RxJS / gRPC и AWS не такие уж тонкие. Более того, вы можете использовать его в конкретном модуле, чтобы определить, какой каталог виноват. Это позволило нам обнаружить, что у RxJS есть версия для ts, es5, es2015 и пакета UMD, хотя мы используем dist напрямую.

Эти дополнительные пакеты занимали 7 МБ из 11 МБ всего пакета. Более 50%!

Та же история была с gRPC (был каталог из нескольких сторонних производителей, который мы вообще не использовали - около 12 МБ) и AWS (вы получаете версию для Интернета и встроенную в комплекте - около 10 МБ). По этой причине мы создали специальный сценарий оболочки, который производил очистку.

Благодаря этому мы снизились еще на 17%, то есть со 126 МБ до примерно 104 МБ.

Конечный результат

Мы начали с 700 МБ зависимостей. Затем мы немного порубили и оставили только те модули, которые нам действительно нужны. Остальные были заменены на более мелкие модули или даже заменены нашим собственным кодом. В итоге мы получили 256 МБ. После этого мы использовали производственный флаг и превратили его в 176 МБ. Используя node-prune, мы можем уменьшить его до 126 МБ, а затем уменьшить его до 104 МБ после некоторой дополнительной очистки.

От 700 МБ до 104 МБ! Звучит здорово, не правда ли?

Вы не поверите, но все эти шаги (кроме производственного флага) можно использовать и в версии для разработчиков, поэтому мы тоже пробовали это. В итоге у нас осталось 161 МБ для версии для разработчиков. Это меньше, чем при использовании только производственного флага.

И вот так в общей сложности мы потеряли 539 МБ! Ваши node_modules размером с косатку не приносят никакой пользы вашему приложению - они ухудшают производительность, замедляют процессы и поглощают инфраструктуру (что означает, что вы фактически теряете много денег на дополнительных ресурсах). В общем, я настоятельно рекомендую сократить количество модулей node_modules в вашем проекте ради неоспоримых преимуществ для бизнеса. Если вы предпочитаете, чтобы этим занимался специалист, вы можете предупредить нашу команду Node.js. Удачи!

Статья написана Адамом Полаком и впервые была опубликована в Блоге Software House. Посетите блог, чтобы узнать больше о передовых методах разработки и советах по аутсорсингу программного обеспечения.