Здравствуйте, bnk, Вы писали:

A>>Однако, выходит, если хочешь при разработке иметь удобства модульности (ремаппинги, например, для тестовых билдов), то обязан качать все ресурсы с сервера. Это заговор злых корпораций?
bnk>Вообще это сделано чтобы javascript не мог читать локальные файлы, если он вдруг это захочет. И это IMHO есть хорошо.

Javascript при импорте модулей может читать только код, и только куски, помеченные на экспорт. И чтобы он выполнился, на него надо сослаться в разметке (в <script>'е или опосредованно — подменой в карте импорта). Если ты можешь в разметке создавать <script>'ы, ты можешь с тем же успехом подтянуть любой js-файл. Но только не страшный js-файл, оформленный как модуль! Хотя модули даже чуточку безопаснее, из-за запрета на некоторые трюки в strict'е. В этом и вопрос, где тут логика. Логика, ау! Нет тебя, и бога нет. На головы корпораций зла.

bnk>Для оффлайн-приложений (которые не требуют интернета) есть стандартное решение — PWA/web workers, можно все хранить в кэше браузера,
bnk>хоть десятки гигабайтов (увидел тут недавно — народ LLM хранит, лол — образы виртуалок, по сути)

Извращенцы. Есть золотой стандарт — файлы, поддерживаются везде, но нет, надо залезть к чёрту в зубы, привязаться к кэшу браузера. Ссаных npm-зумеров хлебом не корми, дай продуктовый пайплайн завязать на как можно большее число сторонних решений.

bnk>Для встраиваемых браузеров (типа electron или edge web view) это отключается через параметры.
bnk>Также у всех браузеров есть ключ настройки, позволяющий блокировку file:/// отключить (для FF была кнопка-плагин AFAIR)

А вот это уже тема. Спасибо! Действительно, должно же это поведение отключаться.

bnk>В самом тупом случае разработки удобно пользоваться live-server (встроенный в vs code)

В продакшене?