Comments 8
А чем новые модули лучше старых? Я пока вижу только один аргумент: унификация способа подключения модулей в ноде и на фронте. Может быть есть что-то ещё?
Это даже не унификация, а именно стандартизация. ES Modules это часть спецификации ECMAScript т.е. новые модули это нативная реализация модулей, работающая в идеале одинаково во всех реализация движков и производных ECMAScript.
Ещё одно из отличий ES Modules от Common JS это то, что ES Modules по своей природе асинхронны, а Common JS синхронны.
ES-модулям намного легче делать tree shaking (актуально скорее для фронта, где важно количество подключенного кода). Есть возможность асинхронного подключения модуля (что тоже актуально для фронта). Изменения в стандарте package.json поспособствуют увеличению доли пакетов, опубликованных в NPM в формате ES-модуля, что пойдёт на пользу фронту (из-за tree shaking). В остальном это синтаксический сахар.
В общем польза только для фронта, хотя он уже давно использует ES-модули. Бэкэнду только унификация и синтаксический сахар.
Каким образом можно запустить один конкретный файл в режиме ECMAScript, без указания ему "странного" расширения .mjs? Почему нет аналога --input-type=module для запуска файла в таком же режиме?
У нас в проектах имеется множество скриптов, размещённых в файлах без расширения (т.к. скрипты на разных языках и взаимозаменяемы), типа ./scripts/site-import, ./scripts/make-backup, и добавлять туда расширение .mjs специально для скриптов на node.js - будет как-то совсем нелепо...
Запилил ишшуй на эту тему https://github.com/nodejs/node/issues/41136 но там послали на дискашшен, где только разговоры разговаривают, но фиксить не хотят ;(
Анонсируем поддержку ECMAScript модулей в Node.js