<b>esbuild ускоряет сборку, но ломается там, где ждут «магии» от трансформации</b>

<b>esbuild ускоряет сборку, но ломается там, где ждут «магии» от трансформации</b>

esbuild берут за скорость, но часто используют как полный заменитель всего тулчейна. Это ошибка. Его сильные стороны: быстрый транспайлинг, бандлинг, minify, JSX/TS-пайплайн. Слабые: сложные AST-рефакторинги, тонкая проверка типов, нестандартные плагины.

Если у проекта есть:
— нестандартные пути резолва и alias-слои;
— генерация кода на этапе сборки;
— зависимости с ESM/CJS-миксом;
— требования к точной совместимости с Babel/TS transforms,
то esbuild лучше держать как быстрый рантайм для части пайплайна, а не как единственный инструмент.

На практике это выглядит так: TypeScript проверяет типы отдельно, esbuild делает быстрый билд, а Biome или ESLint закрывают стиль и часть ошибок до коммита. Такой расклад обычно лучше, чем пытаться запихнуть всё в один процесс и получить красивый, но хрупкий конфиг.

Есть наблюдение которое стоит проверить: чем меньше «умных» шагов внутри сборки, тем проще ускорять репозиторий без побочных поломок. Если build time уже мешает, сначала выносите проверку типов и линт из сборки, потом упрощайте плагины и алиасы.

esbuild — это отличный мотор. Но мотор не должен решать за вас архитектуру сборки.