Разработка CRM. 017 Переменные, шрифты и базовые стили. Верстка Button 

Планирую на VueJS, но при этом, чтобы не смешивать процессы, решил показать верстку всей статики без каких-либо фреймворков. Как будто мы на данном этапе еще не знаем, на какой технологии будет построен frontend.

@@lectoria А вью нельзя использовать, как сборщик вместо гальпа? Ведь вью на выходе соберёт ту же статику, и не тратить время на настройку галпа.

@@user-um4tq7oj1x Вообще, у vue тоже есть свои инструменты для сборки. Вроде как vite позволяет создавать подобную инфраструктуру. Да и при более глубокой настройке, можно попытаться все это на одном только webpack создать. Но с webpack у меня был опыт такой попытки - то vue-loader несовместим с текущей версией webpack, а когда откатываешь версию webpack, тогда scss-loader становится несовместимым. В общем, много тонкостей и несостыковок. Возможно, что сейчас ситуация улучшилась, но я решил показать именно свой подход, который работает и обкатан на нескольких заказах. Суть от этого не меняется: нужно просто собрать препроцессорные файлы в итоговые js/css/html. Я сознательно на этом этапе отложил использование javascript и vuejs, так как решил действовать поэтапно и концентрироваться на каждом этапе только на одной-двух технологиях. Прекрасно понимаю, что это увеличивает время разработки. Но это, повторюсь, осознанный шаг ) А то, что касается фразы "не тратить время на настройку галп". Когда речь идет о большом проекте на сотни часов, вопрос потратить 1-2 часа на настройку галпа или 1 час на настройку какого-то другого инструмента - это несущественно, в пределах погрешности оценки трудоемкости проекта.

Унификация модификаторов переменных не должна привязываться к конкретным величинам в px или в rem, это просто условная единица, означающая "средний", "маленький", "очень маленький" и так далее. Отступы и радиусы - разные сущности. В какой-то момент может быть редизайн, который подразумевает, что все углы должны стать без скруглений, поэтому все радиусы будут выставлены в 0, но при этом отступы должны оставаться прежними. Поэтому ваш подход не подойдет. Ну по крайней мере, он может стать проблемой, когда нужно будет сделать какие-то изменения в чем-то одном и в итоге будет вводить вас в путаницу.

.base(class!=attributes.class) означает, что будет создан .... То есть, если мы где-то вызываем миксин +base.my-custom-class, то будет создан .... По PUG отдельное видео, честно говоря, не планировал, так как я сам его начал использовать стихийно - взял и начал, не изучая какие-то курсы или огромные мануалы. Просто писал, а как только возникает ситуация, где нужно понять, как пробрасывать параметры, делать циклы или переменные, то просто залезал в документацию.

@@lectoria Странно что !=, а что будет если вот так .base(class=attributes.class) или наверное так .base(class==attributes.class)

@@alexandr-v В pug != означает подстановку неэкранированного значения. Атрибуты же, передаваемые в mixin через attributes, экранируются автоматически (escaped attributes), поэтому, чтобы имена классов второй раз не экранировались, внутри mixin пишем class!=attributes.class, что фактически означает, что внутри миксина мы в атрибут class вставляем неэкранированные значения attributes.class. Если написать class=attributes.class, то будет повторное экранирование и приведет к неожиданным последствиям.

@@lectoria Вот это ОЧЕНЬ важная информация, а то чуть мозг не сломал.