<b>ESM без боли: 5 проверок перед миграцией, чтобы не сломать сборку</b>

<b>ESM без боли: 5 проверок перед миграцией, чтобы не сломать сборку</b>

ESM — это не только синтаксис `import/export`, но и правила резолва модулей, расширения файлов, поле `type`, а также поведение Node, Vite и тест-раннеров. Ошибка обычно не в коде, а в ожиданиях от окружения.

• Сначала проверь, как собирается проект: если у тебя есть `tsc`, Vite, Vitest и Node-скрипты, они могут видеть один и тот же импорт по-разному.
• Не смешивай без нужды CommonJS и ESM в одной зоне. Если смешивать приходится, фиксируй границу явно: `.cjs`, `.mjs`, `type: "module"`.
• В `tsconfig` смотри на `module`, `moduleResolution`, `target`, `paths`. Неверный резолв часто маскируется до первого запуска в Node.
• Импорты с расширением — отдельная ловушка. Для ESM в Node оно часто обязательно, а в бандлере может «магически» работать и потом ломаться в рантайме.
• Утилиты и конфиги тоже важны: `vite.config.ts`, `eslint`, тесты, CLI-скрипты. Один файл в CJS может тянуть назад всю схему.

Если мигрировать поэтапно, начинай с границ: сборка, тесты, runtime-скрипты, потом уже прикладной код. Так меньше шансов получить проект, который собирается, но не стартует.