Александр Викторович

Что-то мне подсказывает что у вас перспектива включена

Выберите «Просмотр» > «Сетка перспективы» > «Скрыть сетку».

CDN vs свой билд — экономия на спичках.
Тем более если вам не нужен весь пакет.

Начну с самого плохого, неправильного и убогого варианта использования:
Это когда люди подключают бутстрап.мин.цсс, а потом в своем файлике начинают переопределять стили. Получается полный неподдерживаемый пиздец (я как раз сейчас натягиваю на сайт купленный (!) такой шаблон, нервы на пределе).
Люди, которые так делают приводят гнилой аргумент: а вдруг мы захотим обновить бутстрап? Серьезно, блять? Как часто вы это делали? ставлю сто баксов, что ни разу.

Как делать по феншую.

Для начала, естественно, использовать препроцессорные исходники (не будем выбирать конкретный порт, есть и lеss, и sсss, и stylus, кому что нравится).

Далее миксины. Не нужно подключать отдельные. Подключите valiables.scss и mixins.scss. Миксины не попадают сами по себе в билд, так пусть они все будут доступны.

Компоненты. Отключите ненужные, закомментировав импорты соответствующих файлов.

Кнопки. Если бутстраповские не нужны, отключите их. Напишите свои, используя миксины и даже копипасту части кода из бутстрапа. Это нормально.
Отличный вариант, если вы напишете свой миксин для кнопки (который и бутстраповские миксины может использовать). Ибо в бутстрапе, к сожалению, нет миксина make-button().

Если вам нужно переделать компонент или стиль (часто приходится модифицировать навбар, таблицы, навигацию, табы), не стесняйтесь исправить исходник. Но лучше исходнить отключить, скопипастить и подключить свой вариант (возможно даже поменяв классы, но это не всегда прокатит, ибо связанность ужасная). Править нужно, понимая что вы делаете. Потому что бутстрап внутри устроен через жопу. Взять хотя бы класс .nav — лютый пиздец, дикая связанность.

Пагинация, крошки. Никогда вас не попросят поставить исходные стили. Если по макету эти элементы имеют определенный стиль, этот стиль будет сохраняться. Смело меняйте. Или делайте дубликат.

Хелперы использовать нужно как можно меньше. Они нужны для быстрых набросков или правок "здесь и сейчас". Лучше опишите новый класс.
Опять же если вам нужен класс list-inline в единственном месте, то почему бы его не прописать?

Ссылки и статьи типа "как верстать под бутстрап" — это исключительно отстойный материал, написанный чаще всего такими же новичками, как и те, кто ищет подобную тему. Хотя базовую инфу вы конечно получите.

Объявите в вебпаке по отдельному entry для каждой страницы
https://webpack.js.org/concepts/entry-points/
Вебпак будет собирать несколько бандлов. Подключайте в страницах соответствующие им бандлы.
Так же рекомендую настроить генерацию общего чанка, чтобы общие части JS не дублировались в бандлах, а попадали в один общий.
https://webpack.js.org/configuration/optimization/...
https://webpack.js.org/plugins/split-chunks-plugin/

Нашёл пакет gulp-nunjucks-inheritance

Таск теперь выглядит вот так

function html() {
  return src('src/**/*.{html,njk}', { base: 'src', since: lastRun('html') })

    // Nunjucks
    .pipe(nunjucksInheritance({ base: 'src' })) // Ищем изменения в зависимостях
    .pipe(nunjucks({ path: 'src' })) // Компилируем в HTML

    // Добавляет индентацию для заинклюженных блоков.
    .pipe(prettyHtml({ indent_size: 2 }))

    // HTML-валидатор.
    .pipe(htmlhint('.htmlhintrc'))
    .pipe(htmlhint.reporter())

    // Манифест.
    // Если флаг --dist без --norev.
    .pipe(gulpif(dist, gulpif(!norev, revReplace({
      manifest: src('manifest/manifest.json', { allowEmpty: true }),
    }))))

    // Выгрузка.
    .pipe(dest(buildHtml))

    // browserSync.
    .pipe(gulpif(!dist, browserSync.stream())); // Если нет флага --dist.
}

Обязательно в src указывайте путь до всех .njk файлов, иначе пакет отказывается работать.

Есть сборщик gulp

То что под gulp есть сборщики не делает сам gulp сборщиком. Gulp - task runner, запускалка задач. То есть сборщик под капотом может быть любой, хоть тот же vite.
Теперь про vite, основная его фишка - это ускорение dev сборок и за счет этого ускорение самого процесса разработки. Достигает он это за счет того, что по сути не собирает Ваши исходники, а только применяет к ним трансформации, хотя зависимости все же собирает с помощью esbuild. При этом для прода вся сборка переадресуется на rollup. И то что в dev и в prod у Вас будут по сути разные сборщики изредка приводит к багам, которые воспроизводятся только в prod сборках. Rollup надо сказать тоже не идеален и на больших проектах порой ломает код, хоть и редко.

А по факту, смена сборщика чревата ошибками, сильными изменениями в структуре проекта и прочими подводными камнями.
Если вопрос "стоит ли переезжать" появился только из hype-driven-development (погоней за модой по-простому), то ответ однозначный - нет, не стоит.
Если же текущая сборка накладывает на Вас сильные ограничения и борьба с этими ограничениями занимает очень много времени, настолько, что потенциальные проблемы от смены сборки скорее всего займут времени меньше, то да, стоит переезжать.

Шаблон поиска ^[^:]+
Строку замены оставить пустой.

<script type="text/javascript">
        var span = document.querySelector('span.ratingtypeplusminus');
	span.style.visibility = (span.innerHTML == '0') ? 'hidden' : '';
</script>
</body>

В конец скрипт перенести.

А это второй способ, который уже описали:

body{
	overflow-y: scroll;
}

ul li:not(:first-child):not(:last-child) {
...
}

как-то так

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

CSS свойство background – это просто сокращение, позволяющее одним значением установить сразу несколько из свойств background-*:

• background-clip
  
• background-color
  
• background-image
  
• background-origin
  
• background-position
  
• background-repeat
  
• background-size
  
• background-attachment

Указанные значения (в любом порядке) устанавливают свойства точно так же, как и отдельные инструкции. Не указанные сохраняют значения по умолчанию.

Таким образом, background: #F90 полностью эквивалентен background-color: #F90

Например, background: #F90 url(fon.jpg) repeat-x равен

background-color: #F90;
background-image: url(fon.jpg);
background-repeat: repeat-x;

Цвета – разные цветовые модели бывают удобны для разных задач. Например, в модели HSL легко «гасить» свет, изменяя только его компоненту L (яркость), или только уменьшая насыщенность S. Или получить палитру из нескольких цветов, одинаково ярких-сочных, но равномерно разбросанных по кругу оттенков, равномерно раскидав их H по цветовому кругу, а S и L оставив одинаковыми.

Nvm всегда запускаем из-под администратора -> откройте командную строку от имени админа