<b>esbuild берут за скорость, но ломают на нём сборку из-за пары типовых ошибок</b>

<b>esbuild берут за скорость, но ломают на нём сборку из-за пары типовых ошибок</b>

esbuild хорош там, где нужен быстрый transpile и bundling без лишней магии. Но он не заменяет весь тулчейн: часть задач лучше оставить TypeScript, Biome, тестам или отдельному компилятору. Иначе потом удивляются, почему код собрался, а в рантайме поведение другое.

Три места, где чаще всего ошибаются:
— Путают bundle и typecheck: esbuild не проверяет типы, он только быстро превращает код в JS.
— Надеются на полную совместимость с Babel-цепочками и сложными плагинами; если у вас много нестандартного синтаксиса, готовьтесь к ручной настройке.
— Не фиксируют target и platform, а потом ловят сюрпризы в ESM/CJS, top-level await и Node-специфичных API.

Для продакшена полезно разделять ответственность: esbuild — для быстрой сборки, tsc — для проверки типов, Biome — для форматирования и части линта. В monorepo это особенно заметно: один быстрый билд не спасает, если пакеты публикуются с разной модульной моделью.

Если нужен короткий критерий: esbuild — отличный ускоритель, но плохая замена архитектуре сборки. Сначала задайте target, platform и формат модулей, потом уже оптимизируйте скорость.