Комментарии 3
С одной стороны, круто, что в dev-режиме больше не нужно использовать всякую гадость типа node resolve. С другой стороны, если вы контролируете то, как ваш сервер резолвит пути — вам все равно, и, как и раньше, вы можете использовать относительные пути, согласно спецификации, и запускать свой код без сборки.
Текущие карты импортов не решают проблему отсутствия расширения файла, которую допускает вебпак и прочие сборщики. Нужны маски (в идеале regexp)
когда в коде идет пачка:
невозможно использовать одну карту:
но приходится писать всю дичь под каждый модуль (и под вложенные модули внутри других модулей):
когда в коде идет пачка:
import A from 'Helpers/A';
import B from 'Helpers/B';
import C from 'Helpers/C';
невозможно использовать одну карту:
{
"imports": {
"Helpers/": "../../utils/helpers/"
}
}
но приходится писать всю дичь под каждый модуль (и под вложенные модули внутри других модулей):
{
"imports": {
"Helpers/A": "../../utils/helpers/A.js",
"Helpers/B": "../../utils/helpers/B.js",
"Helpers/C": "../../utils/helpers/C.js",
...
}
}
Все что было нужно - это js колбек для импортов, начинающихся не с точки и не со слеша, который дал бы неограниченную свободу при резолве модулей. Который был бы очень простым в реализации. Но эти чуваки решили 5 лет потратить на разработку куцей и бессмысленной спецификации карт импортов.
ПС:. Например, я хочу отсылать все подобные импорты в корень сервера, как есть, где сервер, имея доступ к файловой системе воспользуется механизмом node.js найдет нужный модуль и вернет его по требованию.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Контролируем JavaScript импорты с помощью Import maps