<b>ESM ломает не код, а привычки: 7 мест, где обычно спотыкаются</b>

<b>ESM ломает не код, а привычки: 7 мест, где обычно спотыкаются</b>

ESM нужен не ради моды, а чтобы сборка и загрузка модулей совпадали с тем, как работает браузер и Node. Но при миграции чаще всего падают не импорты, а мелкие допущения: «require везде сработает», «index.ts подхватится сам», «default export и named export взаимозаменяемы».

— в ESM нужен явный file extension в относительных импортax: ./lib.js, а не ./lib
— CommonJS-модуль нельзя бездумно импортировать как default: смотри на interop и shape объекта
— __dirname и __filename не существуют: для них нужен URL-подход
— side effects в модулях становятся заметнее: порядок import имеет значение
— package.json с type:"module" меняет поведение всего пакета, а не одного файла

Если проект большой, начинай не с переписывания всего репозитория, а с границ: отдельный entrypoint, отдельный tsconfig, отдельные правила для тестов и tooling. Иначе в одном месте будет ESM, в другом — CJS, а дальше начнётся вечная магия сборщика ⚙️

Хорошая проверка простая: если модуль можно поднять без трансформации в Vite, Node и тестовом раннере — ты близко к нормальной ESM-базе.