Comments 8
А что если после export something, дописать module.exports = something? Может тогда require сможет его подключить?
Вы не можете использовать в одном файле и require и import. Либо то, либо другое.
Это не так. Вы вполне можете оставить require в ESM, только вам его придётся сначала получить. Тем не менее, при необходимости, имеющийся код с require можно не менять.
Но чтобы nodeJS правильно определял какой это модуль конечные файлы нужно сохранять с расширением .cjs и это важно.
Да ну нет же, достаточно передать параметр типа модулей по умолчанию (или прописать в package.json). Вообще пытаться жить с .cjs и .mjs вместо хотя бы .js и .mjs (а еще лучше вообще взять typescript, и будет .js и .ts, где с ресолвом импортов будет разбираться tsc, делающий это куда лучше ноды) — это из серии "мы легких путей не ищем". И неудивительно, что вы тут же нажили этим дополнительных проблем.
А в целом да, сразу было ясно, что ограничение "из CommonJS ресолвим только CommonJS" приведет к тому, что светлой эры повального ESM не наступит, пока не подтянутся инструменты.
В принципе, вся суть статьи раскрывается вот в этом предложении:
Вызывающий файл electron это CommonJS модуль.
Пока electron это не исправит на своей стороне (вот issue на эту тему) о нативных модулях в electron можно только мечтать.
А всех трудностей со сборщиками можно было избежать, просто удалив type: "module"
из package.json, разве нет?
В свое время решал эту проблему просто подключая в Electron уже готовые сборки из ESM. Это может и не очень красиво, но работало...
Получается два варианта
- Смириться
- Взять (или написать) обертку по типу electron-compile, которая будет выкинута как только инструменты созреют
Интересно почему нельзя было разрешить commonjs модули в ESM? Если бы так было сделано в node.js то не надо было бы всех этих танцев и новых расширений. :/
Неудачный опыт миграции Electron приложения на ECMAScript модули