Комментарии 26
внутри vite используется esbuild ?
Только для dev режима
Я не сторонник подхода, когда для разработки используется одна экосистема, а для production-билда - другая, и легко можно поймать на проде ошибки, которых локально не было. В Vite это именно так, поэтому в коммерческих проектах его не использую. Также перфоманс production сборки через Rollup (его использует Vite) хуже, чем моя текущая связка Webpack+SWC. Конкретные цифры не приведу, но в районе 20%, как и при чистом Rollup. А в дев-режиме ускорение с 0.2с (Webpack+SWC) до 0.1с (Vite) совершенно недостаточно, чтобы сподвигнуть на переход.
К Vite я тоже делал 3 подхода, но каждый раз натыкался на недостаточный функционал и низкий перфоманс, если не использовать ESM-dev-схему, которая мне не подходит, как написал выше. Поэтому тщательно изучать Vite после перехода на esbuild не вижу пока необходимости - скорее более интересно будущее Turbopack.
Вроде Эван заявил на конференции недавно, что все силы сейчас на Vite брошены - переписывают частично Rollup на Rust, будет один сборщик на оба режима
Лучше бы esbuild и для продакшен-сборки использовали и добавили в него нормальное разделение на чанки, чем новый сборщик по факту делать...
And during build time Vite currently uses Rollup where bundling size and having access to a wide ecosystem of plugins are more important than raw speed.
Vite документация
Конкуренция — это хорошо, и если rollup (который умеет нормально разбивать на чанки) смогут в несколько раз ускорить, то это можно будет тащить в продакшн, а не ждать несколько лет (я про неработающее разбиение на чанки в esbuild).
Angular 17 использует ESBuild под капотом, на чанки всё спокойно распиливается. Видимо, они как-то всё-таки его осилили.
Бонусом, само собой, выросла скоро пересборки и, возможно, не в последнюю очередь благодаря этому бандл на Angular теперь производительнее бандла на React!
Тоже недавно перешел на esbuild, но с rollup. Скорость сборки впечатляет. Большое спасибо за плагины, буду использовать.
Чанки собирался сделать через external и importmaps, должно сработать
Вручную такой механизм, не залезая во внутрянку esbuild, будет сложно сделать. Я тоже думал о такой схеме:
до билда смотрим все файлы на предмет асинхронных импортов и собираем новый entry points массив из них
продолжаем сборку со всеми этими entry points
смотрим в метафайле на общие зависимости всех entry points и выносим их в отдельный entry point и прописываем в externals весь этот список
пересобираем
Но как видно из схемы, общие зависимости придется грузить сразу вместе с базовым выходным файлом. Как ни кручу в голове разные сценарии, пока сам esbuild не сможет создавать чанки с соответствующими ссылками на используемые и пересекающиеся зависимости, этот функционал корректно не реализовать. Возможно получится сделать схему из 2-3 последовательных ребилдов, но это не то. Если получится - было бы интересно узнать, как
Я думал по регулярке выделять чанки вроде src/pages/* или src/async/* и собирать их отдельно. Импорт остается тот же самый.
Если хочется на автомате, то это сложнее задача, так сходу и не придумать.
А куда их выделять, в entry массив? Если так - то если в каждом чанке импортится скажем MUI или lodash, то они будут включаться в каждый чанк, и в итоге мы не сэкономим трафик пользователя, а значительно увеличим его, получив еще и проблемы коллизий.
Да, понял проблему. Вручную это сложно будет сделать.
Там ведь еще непонятно, что называть общими зависимостями - те которые для всех чанков нужны или хотя бы для двух. В первом случае грузим слишком много, во втором оверхед из-за большого числа чанков.
Как вариант вынести большие зависимости вроде mui или реакта в externals по-дефолту. А на остальные общие зависимости закрыть глаза
Полумеры для production не подойдут) Либо делать качественную обработку, либо пожертвовать чанками. Никто не будет следить вручную за всеми зависимостями, которые используют чанки - раз сделаешь импорт lodash - прибавится 500кб в несжатом виде, условно. Поэтому и написал в статье, что для тех проектов, в которых нужно минимальное количество js на старте, esbuild не подходит
У esbuild есть существенный недостаток, он не поддерживает все возможности typescript. Как альтернативу рекомендую использовать связку rollup + swc + post-css. Скорость даже чуть лучше, и полная поддержка typescript.
Rollup+swc это аналог webpack+swc. Postcss как я указал в статье уже используется, то есть с css проблем не будет. Скорость однозначно лучше у esbuild, а на счет поддержки ts - можно же использовать esbuild+swc, тогда все, что поддерживает swc, можно использовать.
Подскажите, а какие возможности typescript не поддерживает esbuild?
Сжатие в gzip / brotli
Извините за оффтоп. Как сжатие работает в контексте сборки фронта (Webpack, Esbuild и т.п.)? Насколько я знаю, файлы хранятся не сжатые, и сервер сжимает их непосредственно при отправки браузеру. Серверы умеют работать с заранее сжатыми файлами?
Да, есть серверы, которые могут работать с заранее сжатыми файлами. Например, nginx.
Например Nginx умеет как генерировать gzip налету, так и отдавать уже сжатые файлы, что предотвращает лишнюю работу по сжатию. Для этого нужно придерживаться конвенции index.js -> index.js.gz и использовать директиву gzip_static on внутри конфига Nginx: https://nginx.org/en/docs/http/ngx_http_gzip_static_module.html
На серверах в версии Nginx для Ubuntu этот модуль обычно уже включён.
В дополнение к предыдущим комментаторам, всегда можно добавить соответствующие редиректы вручную. Для node js например таким кодом:
if (req.url.endsWith('.js') || req.url.endsWith('.css')) {
const acceptedCompression = getAcceptedCompression(req);
if (acceptedCompression) {
req.url = `${req.url}.${acceptedCompression.extension}`;
}
}Полный пример - тут.
Спасибо за статью, буду думать о переезде на esbuild :)
Спасибо за статью, буду думать о переезде на esbuild :)
Webpack vs esbuild — уже можно использовать в production?