Aetae

Потестил.
1. Проблема с conslole.log у тебя в русской "c", о чём намекает даже подсветка тут.
2. npm run съедает параметр --env, т.к. считает его своим, чтоб передавать аргументы в скрипт надо использовать разделитель --: npm run build -- --env mode=development.
Ну или выкинуть убогий npm и использвать yarn\pnpm, где такой ереси нет.:)

Почему?
Потому что в классическом виде это один js файл подключённый через script, а в виде модулей - это множество файлов которые дополнительно грузятся внутри script. Ограничения безопасности браузеров по разному работают в данных ситуациях.

Что делать?
Не открывать современные приложения локально. Просто забудь о такой возможности. Установи глобально какой-нить alive-server и запуская через него. Если надо это распространять - прилагай микросервер в комплекте или смотри в сторону всяких виндовых однофайловых вариантов\pdf.

require работает на этапе компиляции. Т.е. во время исполнения он уже должен был собрать все вызовы require и положить их в .js файл. require не может быть динамичным, потому что на этапе исполнения его тупо уже нет - он заменён на то, что он возвращает.

Для решения подобных задач два варианта:
1. require.context - который соберёт все файлы по предоставленному шаблону на этапе компиляции, и на этапе исполнения будет их подставлять. Этот вариант подходит если в папке img уже сейчас лежат все нужные изображения.
2. Если изображения на этапе компиляции отсутствуют, а появляются каким-то сторонним образом в паке потом, то require тебе тут не нужен(и не поможет), просто динамически подставляй пути к ним как в твоём первом варианте.
Путь от корня, если что, можно получить из __webpack_public_path__:
root: __webpack_public_path__,

<img :src="root + 'img/' + message.filename" :alt="message.filename"/>

Очевидно что пакет битый или ты подключаешь что-то не то.
В готовой либе никаких алиасов быть не должно, на то она и готовая.

Можно что-то нашаманить, но в каждом конкретном случае своё, потому что в любом случае через жопу.

У тебя в тегах вебпак, а значит тебе нужны именно его алиасы.

Если ты используешь cra, то придётся костылить, через craco или подобное.

webpack devServer, в частности функция proxy.
Webpack поднимает сервер с горячей перезагрузкой фронта, бэк сервера поднимаешь на других портах, и обращаешься к api прозрачно с помощью встроенного прокси.

Импортировать всю папку можно, но вот получить доступ ко всему - нельзя, можно только написать функцию которая будет забирать конкретный модуль:

function getCommand(file) {
  return import(
    /* webpackInclude: /[A-Za-z0-9-_,\s]+\.ts$/i */
    `./commands/${file}`
  );
}

Ну и типы в обоих случаях нельзя так импортировать.
Типы проверяются перед компиляцией и выкидываются, они никак уже не участвуют в сборке вебпака.
Как ты это себе представляешь?

Возможно тебе просто нужны глобальные типы? Тогда используй .d.ts, и\или подключай их в tsconfig.json.

Магии не существует, друже.
Что на самом деле делает webpack лоадер? Он берёт на вход какой-то файл, что-то с ним делает и выдаёт js-модуль(в виде строки) с результатом + какие-то побочные действия.

Соответственно css-loader для модулей делает (утрировано) 2 вещи:
1. Из входного css генерирует js-модуль с объектом вида

{ [ключ - настоящее имя класса]: [значение - минифицированное] }

и отдаёт результат в js.
2. Выполняет замену в css настоящих имён на минифицированные и сохраняет отдельно.

Чтобы получить то, что ты хочешь - надо добавить некий loader для .js файлов который удалит все импорты css-модулей из кода(но сохраняя результаты) и заменит все обращения вида $style.className на значения из этих модулей.
Погугли, что-то такое кто-то должен был запилить.)
Ну и в любом случае, чтобы это работало нужна гарантия, что никакой динамики у тебя в коде работы с css модулями нет, т.е. что-то такое: $style[somevar + '__bold'], гарантировано сломает любую такую штуку.

Поздравляю, ты нашёл баг в @vue/cli. Заведи им issue на github.

Подозреваю # в пути лишний.

Ты можешь строить цепочки лоадеров: require(`!a-loader!b-loader!c-loader!file')
Но это, на самом деле, неправильно. Правильный подход - прописать все цепочки для нужного расширения сразу в конфиге вебпака, со всеми нужными параметрами и просто делать require(`file').

Нет. Но ты можешь написать свой лоадер, который будет это делать. Это не сложно.
Однако непонятно нахрена козе баян. Просто положи реальный файлик отдельно и всё, чем инлайн ужасы городить. Это прямо противоречит идее модульности, на которой всё это и построено.

Сделайте свой скрипт: "serve": "node ./api/serve.js", а уж в нём что хотите и как хотите вызывайте.

В теории, если vue-cli не лочит эту конкретную настройку webpack: configureWebpack / chainWebpack и output.filename / output.assetModuleFilename.

Документация: pwa.iconPaths?

Отдельные константы? 0_o

const {APP_NAME} = require('./constants');

new webpack.DefinePlugin({
        APP_NAME: JSON.stringify(APP_NAME),
      }),
new HtmlWebpackPlugin({
        title: APP_NAME + " official"
})

Semantic-ui мёртв. Есть активный форк: Fomantic-UI, скорее всего там это пофикшено.