<b>ESM ломает не код, а допущения: проверь их до первого импорта</b>

<b>ESM ломает не код, а допущения: проверь их до первого импорта</b>

В CommonJS многие ошибки прячутся за require и module.exports. В ESM они выходят наружу сразу: строгие пути, явные расширения, отдельные правила для default и named export.

Три места, где чаще всего спотыкаются:
— импорт без расширения в Node-окружении;
— смешивание default export и named export «на глаз»;
— циклические зависимости, которые в ESM проявляются жёстче, чем в CJS.

Если проект уже живёт на TypeScript, проверь связку tsconfig и рантайма. Для сборки важно, чтобы moduleResolution, target и формат выхода не спорили между собой. Иначе код проходит typecheck, но падает при запуске или в тестах.

Отдельно смотри на библиотеки и утилиты: не всё, что красиво импортируется в Vite, так же работает в Node, Bun или при прямом запуске через tsx. ESM любит явность. Чем меньше магии в путях и экспортах, тем меньше сюрпризов в деплое.

Если мигрируешь репу на ESM, начни с одного правила: сначала стабилизируй импорты, потом меняй формат модулей. Это почти всегда дешевле, чем чинить уже собранный стек.