<b>esbuild ускоряет сборку, но только если не заставлять его делать чужую работу</b>

<b>esbuild ускоряет сборку, но только если не заставлять его делать чужую работу</b>

esbuild — это не «замена всему», а очень быстрый транспайлер и бандлер. Его сильная сторона — скорость на больших графах модулей, слабая — сложная экосистема плагинов и тонкая кастомизация, которую часто пытаются навесить сверху без необходимости.

За неделю в репах чаще всего ломаются не сами сборки, а ожидания:
— ждут, что esbuild сам разрулит все edge cases ESM/CJS;
— пихают в него тяжёлую логику из Babel-плагинов;
— смешивают сборку, минификацию и постобработку в один шаг.

Если нужен быстрый dev loop, esbuild обычно выигрывает там, где важны:
— transpile TypeScript в JavaScript без type-check;
— быстрый prebundle зависимостей;
— простая упаковка без сложных трансформаций.

Если же в проекте много нестандартного синтаксиса, полифиллов и трансформаций AST, лучше разделить роли: esbuild для скорости, отдельный инструмент для проверок и специфичных преобразований. Иначе выигрыш по build time быстро съедается отладкой.

Ещё одна типовая ошибка — надеяться на `target` как на магию. Он не добавляет полифиллы, а только ограничивает выходной синтаксис. Для старых окружений это важно: сначала проверяй, что именно должно быть переписано, а что — подключено отдельно.

<b>Правило простое: чем меньше «умной» логики внутри сборки, тем полезнее esbuild.</b>