Почему сборка фронта на vite внезапно стала жрать 8 гигов памяти и падать

[nixos_andy]

Сборка фронта на vite начала отжирать 8+ гигов и падать с JavaScript heap out of memory, причем буквально на ровном месте, код почти не менялся за неделю. Проект средний, React + TS, около 600 модулей, билдится в CI на раннере с 4гб памяти и теперь стабильно умирает. Локально на маке с 32гб собирается но память пухнет до 6-7 гигов, чего раньше близко не было. Грешу на обновление зависимостей, на той неделе апнули кучу пакетов через renovate. Куда копать, кто ловил такое после апдейта?

[john_rih]

renovate апнул и сломал, классика. первым делом смотри что приехало в lock-файле. у нас был ровно такой кейс когда подтянулась минорка одного rollup-плагина и он перестал тришейкать, память улетала в космос. откати lock на прошлую неделю и собери, если ОК значит виноват апдейт, дальше бинарным поиском ищешь конкретный пакет

[SparkMain]

8 гигов на 600 модулей это ненормально вообще, обычно что то одно сошло с ума. чаще всего это либо барреля (index.ts который реэкспортит все подряд), либо какой нибудь плагин для иконок который инлайнит svg как компоненты и плодит тысячи модулей из ничего. проверь сколько реально модулей в графе через build с флагом отчета

[weekendghost]

ставил NODE_OPTIONS=--max-old-space-size=4096? хотя если уже за 8 улетает это пластырь а не лечение

[android_roman]

ставил NODE_OPTIONS=--max-old-space-size=4096? хотя если уже за 8 улетает это пластырь а не лечение

именно пластырь, причем вредный. поднимешь лимит, в CI раннер на 4гб все равно прибьет процесс по cgroup, и ты будешь думать что node виноват а это OOM killer ядра. сначала найди что жрет, потом уже лимиты

[robin54]

у нас источником оказался source-map. где то в конфиге включились sourcemap: true для прода после мержа чужой ветки, и vite держал в памяти карты на весь бандл. вырубили для прод-сборки, память упала вдвое моментально. глянь свой build.sourcemap, очень частая причина что характерно

[idlebteam]

по делу, разберу как ловить такое системно, сам три раза наступал. шаг первый, воспроизводишь локально с замером, запускаешь сборку и смотришь пик памяти, на маке через /usr/bin/time -l vite build, на линуксе /usr/bin/time -v, тебе нужна цифра maximum resident set. шаг второй, проверяешь не подскочило ли число модулей, ставишь rollup-plugin-visualizer и смотришь граф, если модулей вместо 600 стало 4000 значит какой то плагин тебе их наплодил, чаще всего это иконки или барреля index.ts с export star. шаг третий, отключаешь sourcemap для прода если включен, это самый частый виновник внезапного роста. шаг четвертый, бинарный поиск по lock-файлу, откатываешь renovate-апдейт целиком, собираешь, если ок возвращаешь пакеты половинами. у меня в последний раз виноват был апдейт плагина который сломал тришейкинг и в бандл потащило весь lodash вместо трех функций, память с 2 до 7 гигов. и да, в CI бери раннер хотя бы на 8гб, фронт нынче пухлый, на 4гб собирать средний проект это лотерея. dev сборка кстати память не показатель, там esbuild и лимиты другие, мерь именно build.

[seniorsamurai]

спасибо, sourcemap и правда был включен после чужого мержа, выключил для прода, пик памяти упал с 7.2 до 3.1 гига, в CI собралось. отдельно нашел барель с export * на 80 модулей, тоже разнес по точечным импортам. отметка для тех кто найдет тред потом: копайте sourcemap и реэкспорты в первую очередь