Aetae

const routes = [
  {
    path: '/:id/about-item/:id2',
    name: 'about-item',
    component: aboutItem,
  },{
    path: '/:id',
    name: 'item',
    component: home,
  }
]

Нет смысла делать одно и тоже. Различать по route.params.

1. У тебя вообще запрос не проходит, cors не полностью настроен на сервере.
2. Даже если будет настроен - кука поставится для сервера, а не для клиента, т.к. адреса разные.
3. Если в проде домен бэка и фронта будет един, то просто используй proxy встроенный в devServer.

JSON.stringify(item.SIZES)
Только так делать не надо. Вам не нужен массив в data. Всё что вы делаете с этим массивом - вы должны делать прямо с ним в пределах vue.

В node_modules лежат собранные готовые пакеты, вам туда лезть не надо.

Структура проекта, создаваемая vue-cli соответствует (очевидно) выбранным опциям.
Но эта структура - не что-то сакральное единственно верное. Всё что создал vue-cli вы можете создать вручную. Или создать совершенно другую структуру. Важна лишь логика в коде, папочки не важны.

Так что устанавливая какие-то пакеты вручную вы делаете именно это: устанавливаете пакеты. Т.е. (утрируя) просто кладёте их в node_modules и прописываете их наличие в package.json.
Это никак не влияет на ваш код. Если вы хотите их использовать в коде - вы должны использовать их в коде. Создавать отдельные файлы и папки, или просто подключать в уже имеющихся - ваше дело.
vue-cli делает это за вас, при выборе опций, но это особенность vue-cli, а не неотъемлемое свойство npm пакетов.

Убери ведущую / из всех children.

child "entry" fails because ["entry" is required]]]

Если юзаешь pages, то entry - обязательный параметр. Это точка входа для страницы. Обычно: "src/main.js".

> vue init webpack 'name'
Нет там такого. Это просто синтаксис команд от vue-cli 2.x, последнее обновление которой было 2 года назад. Сейчас есть только vue create.

В целом же: webpack - универсальная система сборки приложения, vue-cli(-<some>) - набор тулз для работы конкретно c vue, внутри использующий в том числе webpack со множеством преднастроек и плагинов.

Кинь в корень проекта файлик .browserslistrc примерно следующего содержания:

> 1%
last 2 versions
ie11

А в настройки'@babel/preset-env' добавь:
useBuiltIns: 'usage'

Дальше babel будет сам подключать нужные полифилы для заявленных браузеров. Если он конечно в принципе правильно подключён и работает.

Конкретно по зоопарку либ у тебя - нет так быть не должно, но бывает. Если работает - можешь в принципе забить, однако если есть время - лучше начать чистый проект со свежего стартового пресета и перенести в него код.

Примерно так.

vue-cli-service build --mode development

Ну и:

configureWebpack: {
    devtool: 'source-map'
}

serve - это только для разработки, доступ соответственно есть только с локалхоста.
Можно разрешить доступ с других хостов, но не рекомендуется.

Если общего функционала больше (условно) половины кода - один компонент. Если меньше - два компонента и один миксин.

Компоненты в Vue должны по хорошему быть капсулированы. Соответственно снаружи компонента post ты никак не должен навешивать класс post__<some>, это внутренний класс компонента. Если снаружи предполагается какая-то модиикация содержимого компонента - то только через props или slot. Назначаемый компоненту класс должен иметь влияние только на сам компонент целиком и не должен ничего знать о внутренней структуре.
Внутри же самого компонента ты можешь поступать любым образом, как будет удобнее. Но поскольку Vue предоставляет v-if и v-show, то предпочтительнее юзать оные.

Оно там будет уже где-то на сервере в момент исполнения или оно там есть ещё на этапе компиляции?

Если второе, то это возможно и не сложно, но зависит от того упаковщика, которым вы пользуетесь.
Например в webpack можно воспользоваться require.context получив файлы в определённой директории.

Если первое, то в общем случае это невозможно: клиент не знает, что у вас там на сервере. Сервер должен будет тем или иным способом передать в приложение путь к файлу.

Технически 0xD34F верно сказал.
Архитектурно же в v-for не желательно использовать сложные вычисления, правильно сделать computed свойство, возвращающее подготовленный и отфильтрованный массив сразу нужного вида.

Если нужда адекватная - дописываете код, делаете PR автору и в следующей версии наслаждетесь.
Если нужда особая своя - делаете форк и либо публикуете в npm(никаких ограничений на это нет) в своём неймспейсе, либо просто кладёте в проект и линкуете свою локальную версию через link:./path или file:./path.

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

Очевидно что вся суть SSR в том что он работает и на сервере и на клиенте. В принципе можно конкретно для серверной стороны прокинуть туда все серверные же модули, но как ты собрался лезть в ту же базу на клиенте?
SPA какбэ работает динамически на клиенте, подгружая по ajax только данные, серверная же часть при SSR отрабатывает только при обращении по прямой ссылке.
Т.е. либо тебе придётся посылать всё гавно из базы для для всех компонентов сразу на клиент при загрузке, либо таки внутри каждого компонента делать дополнительные запросы на сервер за данными, а значит всё равно нужно ajax api к базе.

По mousedown - setTimeout, по mouseup и mouseleave - clearTimeout.
Какие проблемы?