Comments 11
В современном JavaScript осталось два основных стандарта модульных систем.
А что случилось с AMD?
0
Подробнее об этом процессе можно прочитать в статье «Глубокое погружение в ES-модули в картинках».
Так же статья, но грузится быстрее и меньше весит.
+1
Бардак в JS с модулями. Бардак. Писал тулзу на тс, вебпаком собрал, оказывается нельзя просто так взять и заимпортить без нпм этот скрипт. Пошёл читать что с этим делать, выяснилось, что нужно делать кучу бандлов для разных случаев, типа для импорта скрипта в браузер одно, для работы с вебпаком второе, ещё что-то… Короче, ужас. Если у кого есть статейка нормальная про импорты и конкретно про правильную упаковку либы в вебпаке для всех случаев, то буду признателен.
0
Хотел сделать в этой статье раздел про Webpack, но базовая часть про модули получилось большой и решил разделить их на две. Поэтому планирую после Нового года дооформить вторую часть про работу с модулями в Webpack и трюки при работе с Jest( моки, прокидывание alias и т.д.) Если планы не изменятся)
+2
function counter() { /* ... */ }
export counter;
Судя по стандарту (https://tc39.es/ecma262/#prod-ExportDeclaration), такого синтаксиса ведь нет?
Если переменная уже объявлена, экспортировать её под каким-то именем можно только через синтаксис именованных экспортов, в фигурных скобках:
export { counter };
Аналогично и в следующем отрывке (без фигурных скобок будет синтаксическая ошибка):
function counter() { /* ... */ }
export counter as rainbowCounter;
Дублирование дефолтных (или именованных) экспортов тоже является синтаксической ошибкой (https://tc39.es/ecma262/#sec-module-semantics-static-semantics-early-errors):
const awesomeValue = 42;
export { awesomeValue as default };
export default function counter() { /* ... */ }
export default class User { /* ... */ }
Хотя webpack, заменяя эти экспорты на свои внутренние CommonJS-экспорты, фактически убирает эту ошибку.
+1
Sign up to leave a comment.
Модули в JavaScript