Максим Морев

Сомневаетесь - смотрите исходники.

Вкратце - это обёртка над router.push/replace(), изначально созданная исключительно в качестве сахара (да, чтобы не писать useRouter()), потом её научили выполнять редирект на стороне сервера, а потом научили справляться с внешними урлами.

все используют router.push

Это появилось только в Nuxt 3, который всё ещё не то чтобы production-ready, поэтому не успело примелькаться.

Всегда используйте navigateTo. :)

Возьмите qs-stringify

Установить `@pinia/nuxt` недостаточно, нужно установить и саму `pinia`.

npm install pinia

`let` !== `Let`, названия ключевых конструкций языка - регистрозависимые и сЛаВа бОгУ.

P.S. Поймал себя на мысли, что вообще никогда не пытался их писать хотя бы даже с заглавной буквы.

P.P.S. Иногда (всегда) ошибка нужна не только для того, чтобы понять, что программа не работает, а ещё и для того, чтобы понять, почему.

Есть расширение SCSS IntelliSense, оно ищет декларации по всему, что находится в воркспейсе

Нет, подход неправильный.

Несколько вопросов, позволяющих натолкнуться на правильную мысль:
1) Что, если товаров несколько миллионов? Будете хранить весь миллион `items` и выдёргивать его каждый раз?
2) Что, если в корзину нужно положить два одинаковых товара?
3) Обычно товар в корзине не имеет все характеристики сразу (`sizes` в вашем случае) сразу, характеризуясь лишь некоторыми свойствами

А ещё в корзинах обычно дофига внутренней бизнес-логики, которую на фронте держать...
Ну, наверное, можно, но практика показывает, что чем сложнее требования бизнеса, тем менее целесообразно это всё делать на фронте.
Всякие "если товаров определённого типа с определённым свойством в корзине более пяти штук, а ещё сегодня пятница и в админке поставлена галочка, то примени к этим товарам скидку в 50%, но не более 10 000 рублей, не суммируя с другими скидками" - это традиционно задача на бэкенд.

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

Вы ведь сами понимаете, что это ваш косяк, а не заказчика? А чего ему за него платить?

Мне прям вспомнилась ситуация, когда я пришёл к стоматологу вылечить кариес (пусть будет 2 000 рублей), мне рассверлили весь зуб и заявляют "батюшки, да тут же пульпит!" (12 000 рублей).
Помогите Маше найти фразу для стоматолога, которая позволила бы сохранить хорошие отношения.

И вот вы сейчас, по прошествии 2 месяцев, оставите заказчика один на один с незавершённым проектом, в котором никто не разберётся (то есть по сути ни с чем) - то вы поступаете как чудак. Я же вижу по тексту, что понимаете.
А сюда вы за индульгенцией пришли? :)

Хотите "сохранить отношения" - доделывайте как есть, в будущем будете мудрее.

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

Два совета на будущее:
1) Перезакладывать стоимость и время разработки;
2) Если понимаешь, что всё идёт не по плану/пропал интерес / слишком сложно / некомфортно / whatever - сказать об этом сразу и отказаться от проекта, так всегда получается честнее

Опыт всегда стоит дорого, а 53 000 рублей - ну не самая большая цена его получения :)

Вот видите - если "оставить как есть", то у вас не возникает вопросов, как с этим работать, а вторая идея - вызывает.

Риторический вопрос - как с учётом этого факта будет "правильно"?
Нериторический вопрос - а вы чего боитесь в первом варианте и как эту проблему должен решить второй?

Объект с ключами в виде ID для такого толка коллекций иметь удобно, но это не должно быть основным путём хранения данных, если вам важен порядок элементов. Сделайте геттер, который будет брать исходный массив и собирать из него объект в нужном виде.

Кстати, если используете Vue3 - у вас нет ни одной причины не перейти на Pinia вместо Vuex, это более удобный инструмент абсолютно во всех отношениях. :)

приходит от бэка, в формате '2021-11-24 20:17:39'

Пробел на T замените, оно у вас падает ещё на этапе new Date('2021-11-24 20:17:39')

Регулярное выражение должно быть только в строке поиска, в строке вставки вы можете сделать ссылки на найденное, используя группы.

Строка поиска: src="img/(.+)\.jpg"
Строка вставки: src="{{asset('/img/colorit/$1.jpg')}}"

Точно так же, как вы этого добились на кнопке "Submit".
`input` завернуть в блок и вынести стилизацию на него, сам `input` при этом будет просто прозрачным блоком, растянутым по его контейнеру, с обратным значением `skew`.

Если откроете консоль, то обнаружите там ошибку
Uncaught ReferenceError: Swiper is not defined

В вашем случае вам надо поменять местами скрипты, где вы подключаете файлы.
Сначала swiper-bundle, потом вам инициализатор.

Здесь используются медиа-запросы, просто реализация скрыта за миксином.
Вы всегда можете посмотреть в результирующем CSS, во что этот миксин разворачивается.

Сам миксин почти наверняка выглядит как-то так и разворачивается примерно вот в такое:

@media (min-width: 320px) {
  gap: calc(20px + 40 * (100vw - 320px) / 850);
}

@media (min-width: 1170px) {
  gap: 60px;
}

<component :is="x === 1 ? A : B" />

Также работает со строками, если компоненты зарегистрированы локально/глобально/вообще из HTML:

<component :is="x === 1 ? 'div' : 'my-component'"></component>

Ваша проблема решится с помощью -webkit-tap-highlight-color

Критерии "лучшести" какие?
В поддержке обычно проще и очевиднее иметь дубль с говорящим названием: `.block__text` и `.block__text-mobile`, например. Иногда, если контент отличается прям сильно и в нескольких элементах, вплоть до замены самой корневой сущности: `the-hero`, `.the-hero-mobile`, хотя это крайний случай, конечно.

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

* Это не модификаторы, а элементы

Длинными могут быть настолько, насколько это требуется, и в количестве любом, методология это не регламентирует.

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

уменьшат мне варианты названия других основных блоков на странице

Создавайте внутренние блоки с общим неймспейсом, в вашем случае основной компонент - `profile`, внутренние - `profile-info`, `profile-page`, и складывайте их так, чтобы связь родитель-ребёнок между блоками была очевидна.
Ну, да, в таком случае формально вы больше не сможете создать не-дочерний блок с неймспейсом `profile`, чтобы не запутаться, но тут нет других вариантов, и выбрать надо меньшее из зол.

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

Я вот здесь отвечал на похожий по смыслу вопрос - посмотрите.
https://qna.habr.com/q/1129178#answer_2136844