esbuild нужен не везде: где он ускоряет сборку, а где только маскирует проблему

esbuild нужен не везде: где он ускоряет сборку, а где только маскирует проблему

Есть наблюдение которое стоит проверить: esbuild почти всегда выигрывает там, где узкое место — парсинг и трансформация TS/JS. Он хорош как быстрый компилятор, минификатор и слой для dev-сборки. Но если у вас тяжёлый граф зависимостей, странные плагины или много логики на этапе бандлинга, ускорение может оказаться косметическим.

Смотрите на три вещи:
— время cold start и rebuild;
— размер итогового бандла после одинаковых настроек;
— сколько магии живёт в плагинах. Чем больше нестандартной обработки CSS, SVG, MDX и alias-цепочек, тем выше шанс, что esbuild станет только одним из этапов, а не всей сборкой.

Практика простая: для разработки держите быстрый путь, для релиза — отдельную проверку чанков, tree-shaking и sourcemap. Если после перехода сборка стала быстрее, но бандл вырос или сломалась часть кейсов, значит вы ускорили инструмент, а не продукт.

Хорошая схема — измерять не «нравится/не нравится», а две метрики: build time и bundle size. Если первая падает, а вторая не распухает, esbuild отрабатывает свою роль.