Мне очень сильно импонируют namespace'ы в таких языках программирования, как Java и PHP. Настолько сильно, что я даже как-то запилил о них статью на Хабре. С тех пор прошло уже почти два года, но namespace'ы в JavaScript за это время так и не появились. "А если бы я делал namespace'ы в JS для самого себя, то какими бы они были?" - подумалось мне. Под катом - мои соображения, какие же namespace'ы мне нужны в JavaScript'е. Все мои рассуждения ниже применяются к ES6-модулям и не касаются других форматов (AMD, UMD, CommonJS) просто потому, что мне интересно смотреть, куда движется JavaScript, а не где он был. Также я в своей практике как-то достаточно плотно столкнулся с GWT, после чего у меня образовалось стойкое неприятие различных транспиляторов (а также, до кучи, минификаторов и обфускаторов). Поэтому vanilla JS и никакого TS. Ну вот есть у меня такие пункты. ES-модуль - это отдельный файл с исходным кодом, в котором в явном виде определены элементы, доступные снаружи модуля: Таким образом, для начала, нужно каким-то образом адресовать отдельные ES-модули в рамках всего приложения. Современные приложения состоят из отдельных пакетов, зависимостями между которыми управляют менеджеры пакетов. А уже сами пакеты состоят из отдельных модулей. Отдельный разработчик (vendor) может разложить свой код по множеству пакетов, используя одни и те же пакеты в различных своих приложениях. Исходный код модулей обычно помещают в отдельный каталог внутри пакета (например, ./src). Менеджеры пакетов помещают все пакеты одного приложения в каталог node_modules. Таким образом, структура nodejs-приложения, собранного из пакетов определённого разработчика, может выглядеть примерно в таком виде: В файловой структуре исходный код любого ES-модуля адресуется путём к файлу относительно корня приложения: В рамках загрузчика модулей nodejs-приложения часть ./node_modules/ уходит: Если обращаться к модулям в рамках одного пакета, то отпадает и имя пакета, а адресация задаётся относительно точки вызова импорта: Если развернуть web-сервер так, чтобы корень web-приложения указывал на папку node_modules, то с индексной страницы web-приложения можно будет загружать ES-модули, используя почти такие же адреса, как и в nodejs: или при помощи динамического импорта: Проблема в том, что для web'а нужно использовать ./ в самом начале. Если попробовать использовать просто: то браузер выдаст ошибку: Uncaught TypeError: Failed to resolve module specifier "@vendor/package1/src/module1.js". Relative references must start with either "/", "./", or "../". Таким образом, при импорте имеется три варианта адресации одного и того же ES-модуля: локальный (внутри пакета): ./module1.js серверный (nodejs): @vendor/package1/src/module1.js браузерный (web): ./@vendor/package1/src/module1.js Мы должны при импорте применять адреса модулей без ./ в nodejs-приложениях, и адреса с ./ для браузеров. Другими словами, чтобы один и тот же JS-код мог быть использован и на сервере, и в браузере без изменений, нужно применять динамический импорт и вычислять адреса модулей (и лучше всего - абсолютные) на лету, в зависимости от среды выполнения (сервер или браузер). Если "натянуть сову на глобус" (провести аналогию с другими ЯП, в которых есть namespace'ы), то каждому ES-модулю в структуре приложения можно поставить в соответствие некоторую строку (логический адрес), которая могла бы однозначно адресовать положение ES-модуля в пространстве исходных файлов приложения, одинаковую, как для nodejs, так и для браузера. Например, мы можем опустить символы ./, которые требуются в браузере, а также расширение (как правило, внутри пакета используется одно и то же расширение для исходников): Обычно в пакете исходники находятся в каком-то каталоге: ./src/, ./lib/, ./dist/. Эту часть также можно опустить из адреса модуля - очень редко, когда все исходники в пакете размазывают по разным каталогам, а не помещают в один: Я не вижу, что ещё можно удалить из этой строки, поэтому пусть она и будет являться логическим адресом модуля. Чтобы подобная адресация заработала, нужно составить карту соответствия логических адресов физическим адресам пакетов и расширениям, в них используемым. Можно даже добавить какой-нибудь промежуточный каталог для web-карты, если на node_modules указывает не корневой каталог web-сервера (в примере - ./packages/): Далее нужен загрузчик, который бы сопоставлял 'логические' адреса модулей (типа @vendor/package1/module1) их физическим адресам (абсолютным или относительным - лучше абсолютным) в зависимости от среды использования (node или браузер): и использовать его для динамического импорта модулей. Разумеется, нет нужды маппить каждый модуль в пакете - достаточно замаппить корень пакета. На выходе получаем нечто подобное: Импорт модулей должен быть асинхронный, т.к. внутри будет использоваться асинхронная функция import().  Вот таким элегантным образом можно было бы перейти от физической адресации ES-модулей при импорте к их логической адресации (namespace'ам) и использовать одни и те же модули как для nodejs-приложений, так и в браузере. Ничего нового тут не придумано (нечто подобное уже сделано в PHP, откуда эта идея и спёрта).  wiredgeese.com