Максим Морев

Это точно не `chore`, так как относится к продакшен коду.
`chore` - это всё что угодно вокруг кода, если не заведено более узкого типа.
Линтеры (если не используете `style`), настройка CI (если не используете `ci`), всевозможный дополнительный тулинг вроде `husky` или `lint-staged`, незначимое обновление зависимостей и так далее.

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

Если хотите строго следовать, то ваша правка - либо `fix`, либо `feat`.
Я же для себя и для команды ввёл дополнительный тип `temp` (от `temporal`) как раз для такого толка изменений.
Когда "приходит время", можно просто поиском по этому типу быстро его найти и сделать `revert`.

Ещё расширил типом `nvm` (от `nevermind`) для исправлений в духе "забыли пробел в readme" и прочего незначительного.
Хоть формально это может быть выражено через `docs`, `refactor`, `style` или `fix`, от наличия таких коммитов в changelog'e никому ни горячо, ни холодно, поэтому они просто в него не включаются.

Расширяйте конфигурацию до необходимого вам и вашим изменениям, и всё будет хорошо.
* Однако, опыт и здравый смысл подсказывает, что чем типов меньше, тем меньше вероятность ошибки и тем больше шанс, что ими будут пользоваться. Без фанатизма, короче :)

> Есть что-то полегче, но такой же крутой
Это взаимоисключающие вещи ;) У Swiper нет реальной конкуренции.

И откуда вы взяли 150кб?
Он даже в своей 4 версии весил максимум 120, ныне разбит на модули много лучше и его ядро весит 63Кб.

Вот здесь отвечал на похожий вопрос, там найдёте файл, в котором вносятся изменения, а также ссылку на документацию со всеми токенами.
Вам нужен `editorCursor.foreground`.

Эта разметка абсолютно правильная в двух случаях:
1) Ваши `close` и `card` действительно нигде не переиспользуются;
2) Объём стилей блока `some-class` остаётся адекватным для восприятия.

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

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

<div class="block">
  <!-- Header -->
  <div class="block__header">
    <h2 class="block__title">Title</h2>
    <div class="block__actions">
      <button type="button" class="block__action block__action--edit">
        <span class="block__action-icon"></span>
      </button>
    </div>
  </div>
  <!-- Content -->
  <div class="block__content">
    <p>...</p>
  </div>
  <!-- Footer -->
  <div class="block__footer">
    <div class="block__about">
      <div class="block__author"></div>
      <div class="block__date"></div>
    </div>
    <div class="block__awards">
      <div class="block__award">
        <div class="block__award-inner"></div>
        <div class="block__award-tooltip">
          <div class="block__award-tooltip-content"></div>
          <button type="button" class="block__award-tooltip-close"></button>
        </div>
      </div>
    </div>
  </div>
</div>

Положим, что весь контент этого блока уникальный и никак не переиспользуется.
Объём стилей `block` при такой структуре неизбежно станет некомфортным для восприятия, строк на 200-300.

В таком случае хорошо создать внутренний блок (или несколько) просто для того, чтобы размазать сложность.
`block-header`, `block-footer` или даже `block-footer-award`.

Самое главное здесь организовать файловую структуру / конфигурационный файл / чем вы там ещё собираете таким образом, чтобы было очевидно, что `block-footer` - это не самостоятельный блок, а внутренний блок `block`, нужный только для упрощения восприятия, и он не может / не должен использоваться в отрыве от него (в этом случае у него не должно быть в названии общего префикса с `block`, чтобы не создавать путаницу)

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

Вам нужно загуглить что-то вроде `mobile console js`, там есть разные варианты.

Я обычно просто втыкаю на время тестов прям инлайном в HTML, чтобы никаких дополнительных пакетов не ставить.
Там внутри всё работает как вы того ожидаете.

<script src="https://unpkg.com/vconsole@latest/dist/vconsole.min.js"></script>
<script>new window.VConsole();</script>

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

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

Выглядит примерно так:


В объекте конфигурации соответственно отключаете ненужные правила:

rules: {
  'sonarjs/prefer-single-boolean-return': 'off',
  'no-unused-vars': 'off',
}

Но лучше не `off`, а переназначьте на свои предпочтения.
Список правил ESLint

Нет, неправда.

Не бывает так, что один и тот же код в одинаковом окружении иногда "отваливается", а иногда "не отваливается".
Я вот за что очень люблю программирование - у всего всегда есть причина.
Чаще всего причиной являются кривые руки. :)

В идеале - да, по факту - оно того чаще всего не стоит, ниже объясню почему.
* Вообще, если у вас такой вопрос возникает, то вам оно, скорее всего, не нужно.

Основных целей две:

1. Автоматическое перестраивание макета в случае использования компонентов
   Вот есть у вас традиционная, любимая дизайнерская сущность "карточка".
   Она вынесена в компонент и используется на N страницах примерно N * 50 раз.
   Приходит клиент и говорит: хочу в карточку добавить внизу большую красную кнопку.
   Вы добавляете кнопку в компонент.
   Если и сам компонент, и все родители, где он используется, сделаны с помощью автолейаутов - на этом ваша работа заканчивается, все страницы выглядят как надо.
   
   Если автолейаутов нет, добро пожаловать либо в "руками передвинуть все экземпляры на всех страницах" (что нудно, скучно, а если клиент завтра передумает, то вообще лол), либо в "ну я вот тут на странице "Карточка v2" показал, как должно быть", что спустя какое-то время ведёт к бардаку на проекте, в котором невозможно найти концов.
   
2. Больше уверенности в том, что всё стоит ровненько
   Что выливается в то, что верстальщику над макетом работать приятнее - он видит автолейаут и он сразу уверен, что отступ между всеми элементами одинаковый.
   Скорее всего, получится сделать `pixel-perfect`, если заказчику это будет важно. А без автолейаутов у вас может быть ситуация, когда между одинаковыми элементами разный отступ.
   * Необязательно будет - можно быть внимательным, но дополнительная уверенность - это хорошо для всех. Технология страхует от ошибок.
   

Теперь о том, почему не стоит.

• Для того, чтобы автолейауты помогали процессу, а не мешали - у вас ещё до начала работы должно быть полное представление о том, что вы хотите в итоге получить.
  Если вы находитесь в процессе творческого поиска - рисуйте как рисуется. Как только кажется, что всё выглядит хорошо - подумайте над лейаутами.
  
• Когда нужно задизайнить сложный, составной компонент с разными вариантами - его реально нужно проектировать, по субъективным ощущениям это гораздо ближе к вёрстке, чем к дизайну - а это вообще другая профессия, и думать там надо по-другому.
  У меня, когда доводится рисовать, компоненты структурно получаются практически такие же, как они и на вёрстке потом будут - и это замечательно в долгосрочной перспективе - бардака меньше.
  Но я - в первую очередь технический специалист, а дизайнер не думает (и не должен думать) как верстальщик, и сделает немного не то и немного не так. Со стороны будет выглядеть чаще всего как "создал себе проблем на ровном месте".
  Кроме того, у этого есть минусы: компонент становится сложнее (порой - прям ощутимо), чем если просто внутри фрейма мышкой расставлять элементы. Это влияет на то, насколько легко другому человеку разобраться, что происходит и внести свои изменения.
  
• В фигме нет (пока нет) абсолютного позиционирования. Пока в ходу хак с фреймом ширины/высоты 0/0 - но это именно что хак, это увеличивает сложность и разработки, и поддержки. Сложные компоненты без этого не заворачиваются в автолейауты никак.
  
• Не очень опытных дизайнеров автолейауты серьёзно ограничивают в творчестве - дизайн получается... Ну, квадратный, что ли.
  
• Не все вещи возможно реализовать на автолейаутах
  

Во всём нужна мера. Должно быть удобно, быстро, надёжно и понятно команде.
А где эта мера - ну каждый ведь для себя решит, верно? :)

Исключительно первый вариант.

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

Видим класс some-block__el--theme-dark, надо найти стили:

1. Вычленяем название блока - переходим к файлу, в котором находятся стили блока (`some-block.scss`)
   
2. Далее либо `Ctrl+F` по модификатору `--theme-dark` (чаще всего)
   
3. Либо сначала к `Ctrl+F` элементу `__el` и внутри находим модификатор
   

Какой алгоритм выбора между 2 и 3 - не знаю, это где-то на уровне профессиональной интуиции, со временем приходит ощущение.

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

P.S. Из этого можно заключить, что "а давайте вообще откажемся от нестинга и будем искать в один приём сразу по классу целиком".
Есть те, кто разделяют это мнение. Я категорически не разделяю, но это тема для отдельной дискуссии. :)
Вам советую остановиться на том, что нестинг отдельных БЭМ-сущностей (элементов и модификаторов) - хорошая идея, а нестинг для композиции БЭМ-сущностей - не очень хорошая :)

P.P.S. И лучше для разделителя между модификатором и его значением использовать что-то отличное от префикса самого модификатора - меньше в глазах рябить будет, когда модификаторов станет 3-4 штуки на одном элементе ^^

Ровно та же самая: https://paveldogreat.github.io/WebGL-Fluid-Simulation/
Есть несколько аналогов, гуглить запросом "webgl|canvas fluid"

Сделайте страницу _.vue, она будет использоваться для всех адресов, если нет более специфичного правила.
В asyncData этой страницы делайте запрос к API и в зависимости от ответа вызывайте либо ctx.redirect, либо ctx.error.

Подробнее об этом можно узнать здесь