Comments 37
А разве само по себе использование tailwindcss не является ошибкой?
<div class="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500">Content</div>Это же максимально нелепо, и это тут ещё стилей с гулькин нос.
Есть же SCSS, идеальный инструмент для работы со стилями. Там тебе и миксины и переменные и условия и циклы и т.д. и т.п.
Но нет, вы не хотите что бы всё было красиво и просто, вы хотите страдать.
tailwind используется для коммерческой разработки, когда людей много. Как думаешь сколько выхлопа css будет если они будут писать ручками или использовать классы к которым уже привязаны стили.
Я не помню когда уже вообще использовал миксины или циклы, ну может когда потребовалось делать рандомные цвета, но это редкий случай. Sass переменные вообще использовать нельзя, их нельзя переопределить через js
Есть же postCss, который может делать еще больше и он быстрее
tailwind используется для коммерческой разработки, когда людей много
Вообще не вижу тут логику и здравый смысл. Какая разница сколько людей? Если работник #6 делает компонент DatePicker'a скажем, какая разница tailwind или css/scss/и т.п.? При чем тут коммерческая разработка? При чем тут кол-во людей?
Как думаешь сколько выхлопа css будет если они будут писать ручками или использовать классы к которым уже привязаны стили.
Компонентный подход, нет? А для всего остального оверхед в несколько килобайт в масштабах проекта это вообще ничто, причем ничто с большой буквы. Потому что в противовес
<div class={styles.item}>Content</div>против
<div class="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500">Content</div>Ну тут как бы все очевидно. Более того, ты никак не зажат по стилям в отличии от tailwind.
Я не помню когда уже вообще использовал миксины или циклы, ну может когда потребовалось делать рандомные цвета, но это редкий случай
Не расстраивайтесь, если вы знаете как их применять и для чего. Ещё наберетесь опыта. Умные и опытные дядьки приведут вам примеры.
Вот один из них:
Я надеюсь вы слышали о таком понятии как адаптивная верстка?
Ну ка, что может быть более удобнее, очевиднее, читаемее, красивее чем вот это?
.item {
// ... some styles
// ...
padding: 40px 0;
@include respond-to-tablet {
padding: 20px 0;
}
@include respond-to-mobile {
display: none;
}
}Где
$media_size__desktop: 1301px;
$media_size__tablet: 1300px;
$media_size__mobile: 767px;
@mixin respond-to-desktop {
@media all and (min-width: $media_size__desktop) {
@content;
}
}
@mixin respond-to-tablet {
@media all and (min-width: $media_size__mobile + 1px) and (max-width: $media_size__tablet) {
@content;
}
}
@mixin respond-to-mobile {
@media all and (max-width: $media_size__mobile) {
@content;
}
}
@mixin respond-to-not-mobile {
// Догадайтесь сами
}
@mixin respond-to-not-desktop {
// Догадайтесь сами
}
@mixin respond-to-not-tablet {
// Догадайтесь сами
}Sass переменные вообще использовать нельзя
Да вы что? Вот прям так, да? Какой кошмар, 9 лет использую, а оказывается нельзя. Ну если вы не знаете о проектировании и что и как лучше использовать, то это сугубо ваши проблемы)
их нельзя переопределить через js
Что?) Для каких утех ради?)) Наверное вы имеете ввиду переключение светлая тема/темная тема?)
Так то есть переменные нативного CSS если вы не в курсе. var(--base-text-color); И их можно переключать через js) А ещё секрет есть, не знаю, вы наверное не поверите
$base_text_color: var(--base-text-color);Переменные SCSS могут содержать переменные CSS. Вот это поворот)
я говорю что каждый пишет по своему. Мне код после другого разработчика проще прочитать на tailwind, чем фигню которую напишут в css. В стили мы помещаем только псевдоселкторы, фоны и тд. что нельзя запихнуть в классы tailwind.
Миксины зло, потому-что люди злоупотребляют ими. Когда в коде видишь scss миксин сложнее блока из js, начинаешь скрепеть зубами. Tailwind ни так красив и ни компактен, да это зачастую лишняя div вложенность. Но это фреймворк, а значит накладывает свои законы и правила. В scss проще сотворить дичь.
в одном проекте это будет @mixin respond-to-desktop в другом @mixin adaptive-XL в другом @include respond($desktop) в другом @media (min-width: 30em) and (max-width: 50em) и пошло поехало
Мне код после другого разработчика проще прочитать на tailwind, чем фигню которую напишут в css
Фигню? Это какую? font-size? padiing? display? такую фигню? Вы вообще в курсе что такое css и какие в нем стили бывают? Или всё что вы видели это bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 ?
Миксины зло, потому-что люди злоупотребляют ими
Что за бред, вы себя под всех подписываете? Если вы не в курсе что это, и как этим пользоваться, то это не говорит о том, что это зло.
Javascript - зло, потому-что люди злоупотребляют им.
Ну и в таком же духе для всего остального, надеюсь вы поняли абсурдность сие высказывания.
В scss проще сотворить дичь.
Какую конкретно?) Вы опять подписываете всех под себя?) Если вы пишете дичь в scss/css, то опять же, это сугубо ваши индивидуальные проблемы.
В Javascript проще сотворить дичь.
В PHP проще сотворить дичь.
В Angular проще сотворить дичь.
Ну и так далее по списку.
в одном проекте это будет
@mixin respond-to-desktopв другом@mixin adaptive-XLв другом@include respond($desktop)
И что? Как бы названия этих функций говорят сами за себя. Один раз вы их увидели и используйте нездоровье. Плюс никто не запрещает сделать для них алиасы, где:
@mixin respond-to-desktop === @mixin adaptive-XL
Tailwind ни так красив и ни компактен, да это зачастую лишняя div вложенность. Но это фреймворк, а значит накладывает свои законы и правила.
Да, всё что тут перечислили это жирные минусы.
а значит накладывает свои законы и правила.
И это тоже жирный минус.
Ну точнее может для совсем зеленого джуна который первый месяц в разработке это норм. Но для всех остальных, это жирный минус. Ибо связывать руки и ограничивать можно только тех, кто не ведает что творит, остальным это сильно мешает и вставляет палки в колеса.
Но если для вас это не очевидно, то вы пока всё ещё относитесь к категории которых лучше ограничивать во всем и не давать сделать шаг влево шаг вправо.
не хотите схлеснуться в легендарной битве, где один будет на tailwindcss, другом на scss писать код. Оценим качество работы, сам код и время сколько ушло, как такая идея?
зачем мне убеждать его? У него пена из-за рта уже пошла. И при чём здесь скорость? Он не быстрее (хотя если пишешь рутину в стиле display: flex почему не воспользовать готовым). И никто не говорит про полный отказ от обычных стилей. Атомарный CSS занимает свою нишу в разработке и это в основном крупные компании, посколь проще поддерживать проекты. Вот и всё ;) Если бы это было ни так, не было бы вакансий с упоминанием tailwind, windi, unocss
Если бы это было ни так, не было бы вакансий с упоминанием tailwind, windi, unocss
А ещё есть вакансии с упоминанием Angular2, ExtJs и прочими "замечательными" технологиями. Занимайтесь.
посколь проще поддерживать проекты. Вот и всё ;)
<div class="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500">Content</div>Да, это прям мечта, так классно и просто поддерживать, прямо загляденье. Вот мы идиоты то, мучаемся, используем scss/css, и пишем ужасные display, padding, font-size и т.п. Бррр, аж кровь из глаз течет от этих ужасных свойств. Ох, а если миксин заюзать, ууу тогда пиши пропало вообще.
.button {
height: 40px;
padding: 0 40px;
display: inline-flex;
align-items: center;
justify-content: center;
border-radius: 5px;
cursor: pointer;
transition: all .3s ease;
outline: none;
border: none;
// Набор стилей для текста из дизайн системы
@include typography('Text Regular_16', '#fff');
&[data-full-width="true"] {
display: flex;
width: 100%;
}
// На мобильных устройствах hover нам может вредить
@include respond-to-desktop-only {
&:hover {
// Цвет из дизайн системы
background-color: color('Purple_3');
}
}
&:active {
// Цвет из дизайн системы
background-color: color('Purple_2');
}
@include respond-to-mobile {
display: flex;
width: 100%;
padding: 0 20px;
// Набор стилей для текста из дизайн системы
@include typography('Text Thin_14');
}
}Целиком делать проект нет смысла, да и сравнивать скорость нет смысла, ибо ctrl+c / ctrl-v из фигмы всегда быстрее.
или fz + tab + 16px = font-size: 16px; как минимум не уступает сокращениям из tailwind.
Просто повторите аналогичный стиль для кнопки, где
@include typography('Text Thin_14');
пусть будет
font-size: 14px;
font-weight: 300;
line-height: 14px;
letter-spacing: 0.02em;
font-family: lalala;@include typography('Text Regular_16', '#fff');
пусть будет
font-size: 16px;
font-weight: 400;
line-height: 16px;
letter-spacing: 0.02em;
font-family: lalala2222;
Есть же SCSS, идеальный инструмент для работы со стилями
А если туда ещё и CSS modules добавить, то станет ещё идеальней)
Никогда не понимал почему существует Tailwind.
Удобно не удобно, но все же есть вакансии где требуется знание tailwindcss, наблюдается его популярность при создании верстки с нуля. Чтобы каждый раз не создавать css. Если у тебя лэндинги, где не нужна поддержка, это будет идеальное решение для быстрого клепания.
Удобно не удобно, но все же есть вакансии где требуется знание tailwindcss
И что теперь? Это не делает этот "инструмент" отвратительным.
наблюдается его популярность при создании верстки с нуля Чтобы каждый раз не создавать css
<div class="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500">
<div class="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500">Content 1</div>
<div class="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500">Content 2</div>
<div class="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500">
<div class="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500">Content 3</div>
<div class="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500">Content 4</div>
</div>
</div>против
<div class="container">
<div class="main-item">Content 1</div>
<div class="main-item">Content 2</div>
<div class="child-container">
<div class="child-item">Content 3</div>
<div class="child-item">Content 4</div>
</div>
</div>Что, серьезно? Вам самому не смешно?
Если у тебя лэндинги, где не нужна поддержка, это будет идеальное решение для быстрого клепания.
Идеальное? Жесть, даже для write only once говнокода это перебор. Тем более вообще ничего с быстрым клепанием тут общего нет, если сравнить с css/scss, ctrl+c - ctrl+v стилей из фигмы в css, вот где быстро клепание, а не вот это вот всё.
я ленивый программист, если можно сэкономить время разработки и деньги заказчика, я это сделаю, принимая во внимание еще сам продукт.
Я привык использовать готовые библиотеки, а не писать их с нуля. Зачем для каждого мелкого - среднего проекта делать свой ui кит? Если можно позаимствовать готовые, покрытые тестами и без нарушения семантики и стандартного поведения компонентов.
А на счет классов, вам никто не мешает использовать директиву @apply
.container {
@apply bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500
}Плюс еще подобные системы задают скелет для дизайн системы и в процессе сборки неиспользуемые классы из tailwind не добавляются.
Использование готовых утилитарных вещей экономит время. У вас могут быть готовые наработки на scss, которые вы можете из проекта в проект переносить, но не у всех они есть.
Взять тот же mui, мне очень удобно использовать на компонентах props, которыми я могу указывать отступы, цвет и т.д., разработчики позаботились о кастомизации; хотя это может быть спорно, т.к. гибкости там не так много.
Ваши аргументы убедят любого новичка, который никогда не сталкивался с версткой, это точно.
В реальности же Вы просто спрятали всю сложность своего примера в других файлах, как это обычно делается в подобных манипуляциях. А пример с TailwindCSS максимально нелепый, вы просто накопипастили какую-то белиберду, чтобы она и выглядела, как белиберда. На самом деле же, код с TailwindCSS зачастую намного читабельнее Вашего.
Вот Ваш пример, примерно написанный на TailwindCSS:
<div class="mx-auto max-w-4xl rounded-lg bg-gray-100 p-6 shadow-md">
<div class="flex flex-col md:flex-row md:space-x-4">
<div class="mb-4 rounded-md bg-white p-4 text-lg font-semibold text-gray-800 shadow-sm md:mb-0">Content 1</div>
<div class="mb-4 rounded-md bg-white p-4 text-lg font-semibold text-gray-800 shadow-sm md:mb-0">Content 2</div>
</div>
<div class="rounded-md bg-white p-4 shadow-md">
<div class="grid grid-cols-1 gap-4 sm:grid-cols-2">
<div class="rounded-md bg-gray-50 p-3 text-gray-700 shadow-sm">Content 3</div>
<div class="rounded-md bg-gray-50 p-3 text-gray-700 shadow-sm">Content 4</div>
</div>
</div>
</div>
Может отпугнуть, если не знаешь, что значат эти классы. Но даже если не знаешь, можно разобраться, если напрячься. А если умеешь с таким работать, это становится максимально удобно и понятно.
В Вашем же примере я не вижу, как всё стилизовано; чтобы что-то поправить, мне приходится искать файлы со стилями, а так еще импорты в десять других файлов и пошло поехало; если у меня уже есть класс, а конкретно тут нужно еще отступ добавить, что мне делать, это целая проблема; нужно придумывать имена для каждого элемента на странице; нужно переживать на специфичность, чтобы стили не накладывались; для каждого компонента нужно держать отдельный CSS-файл, а значит количество файлов и папок сразу удваивается; и т.д. и т.п.
Я делал и так, и так, и прекрасно понимаю все подводные камни обоих вариантов. И для меня абсолютно очевидно, что TailwindCSS намного превосходит любые Ваши предложения. А Вы никогда не писали на TailwindCSS, и в своем невежестве продолжаете проталкивать устаревшие подходы.
И для меня абсолютно очевидно, что TailwindCSS намного превосходит любые Ваши предложения. А Вы никогда не писали на TailwindCSS, и в своем невежестве продолжаете проталкивать устаревшие подходы.
Соболезную. Может для вас ещё очевидно что земля плоская? А я просто никогда не смотрел на нее со стороны, поэтому как дурак думаю что это шар.
Вот Ваш пример, примерно написанный на TailwindCSS:
И показали типичную вырвиглаз кашу и мешанину.
В Вашем же примере я не вижу, как всё стилизовано
Посмотрите в кометах, там есть прям конкретный пример с scss для одной лишь кнопки, повторите его и всё станет понятно. Вот - https://habr.com/ru/articles/858426/comments/#comment_27560452
Соболезную. Может для вас ещё очевидно что земля плоская?
Этот комментарий отлично демонстрирует, как Вы, не имея возможности опереться на факты, начинаете язвить, передергивать и притягивать за уши. Классическая манипуляция, которая лишний раз доказывает, что Вы не правы.
И показали типичную вырвиглаз кашу и мешанину.
Любой код – каша и мешанина, если вы не умеете его читать.
там есть прям конкретный пример с scss для одной лишь кнопки
Я прекрасно представляю, как выглядить код на SCSS, и я знаю, что код на TailwindCSS в реальных проектах смотрится лучше.
Главный вопрос – это что Вы тут потеряли? Если Вы не хотите писать на TailwindCSS, не пишите, вас никто не заставляет. Зачем Вы вообще в чужой монастырь со своим уставом лезете? Мы тут обсуждаем TailwindCSS, а вот это нытье про то, насколько SCSS лучше, мы уже тысячу раз слышали.
Классическая манипуляция, которая лишний раз доказывает, что Вы не правы.
Это мне говорит тот, кто боится написать аналогичный код на своей "чудо технологии" по комменту с кнопкой https://habr.com/ru/articles/858426/comments/#comment_27560452
Смешно. Вы изначально знаете что ваш код получится говном по сравнению с традиционным, и вместо того чтобы это продемонстрировать вы просто пустые слова кидаете. Так что, это у вас манипуляции на уровне детского сада. Тем более пустые. ибо противопоставить код с примером реальной кнопки вы боитесь. И всё что вы можете это бла бла бла и съезжать с темы. вместо того чтобы взять и написать код.
Любой код – каша и мешанина, если вы не умеете его читать.
Да, только мешанина мешанине рознь. Есть мешанина которая легко читается и воспринимается всеми(например css/scss), а есть мешанина которая читается и воспринимается сложно всеми, только вот чтобы хоть что так ещё понимать надо в дополнении потратить N-ое кол-во время в пустую(например tailwind).
Я прекрасно представляю, как выглядить код на SCSS, и я знаю, что код на TailwindCSS в реальных проектах смотрится лучше.
Бла бла бла, где код? Вот же - https://habr.com/ru/articles/858426/comments/#comment_27560452
Главный вопрос – это что Вы тут потеряли?
Т.е. по вашему в круг анонимных живодеров не надо вмешиваться да? Пусть там себе спокойно мучают животных. Ты же не хочешь их мучать, вот и не лезь, не мешай им.
ибо противопоставить код с примером реальной кнопки вы боитесь. И всё что вы можете это бла бла бла и съезжать с темы. вместо того чтобы взять и написать код.
Вы мне предлагаете лекцию по TailwindCSS Вам теперь расписать? Мне образовывать тех, кто не хочет образовываться, неинтересно.
Например, мне придется объяснять, что пример с кнопкой не очень репрезентативен, так как никто не станет такие базовые стили копипастить для каждой кнопки, они выносятся в стили кнопки в глобальном CSS-файле:
@layer base {
button {
@apply h-10 px-10 inline-flex items-center justify-center rounded cursor-pointer transition-all duration-300 ease-in-out;
}
@media screen and (max-width: 640px) {
button {
@apply px-5 text-sm font-light w-full;
}
}
}
Теперь они есть у всех <button> по умолчанию, а особенности мы будем дописывать классами индивидуально.
Если всё равно классы писать, то зачем @apply? Проще нативными правилами CSS всё записать тогда.
Перед началом проекта мы пишем конфиг, где прописываем все доступные цвета, размеры и т.п.
Если мы пишем через @apply, у нас все правила сохраняются, подсказки IDE помогают не накосячить.
Мы теряем все эти рамки, если пишем чистый CSS.
Плюс удобнее в одном стиле всё записать, раз весь код уже TailwindCSS.
P.S. В примере выше я использовал @media зря, тут надо было тоже через брейкпоинты TailwindCSS делать, на самом деле. Не обратил внимание на плохую подсказку ИИ
Так а почему @media зря? Чем плохо вынести за скобку общий множитель?
Windi CSS так умеет, но вот TW нет, насколько мне известно.
Кстати, в препроцессоре и селектор (button в данном случае) не придётся повторять.
Т.е. по вашему в круг анонимных живодеров не надо вмешиваться да? Пусть там себе спокойно мучают животных. Ты же не хочешь их мучать, вот и не лезь, не мешай им.
Такую чушь несете... Я даже слушать дальше не буду. Испугаюсь и убегу лучше)
что Вы тут потеряли?
Содействую закапыванию tailwind'а в пользу более адекватных инструментов =)
Вдруг начинающие прочитают и задумаются "А что так можно было?"
Это может быть хорошо, если написать разметку один раз и забыть об этом, а если у Content 2 чуть-чуть поменяются правила по ошибке или специально, то как потом понимать, как поддерживать это изменение? В случае с классическим подходом это будут разные классы, по названию которых можно определить их назначение, а здесь тупо литералы. Вы же в коде наверняка пытаетесь избавляться от магических констант, а Tailwind, наоборот, поощряет их создание.
Если у Content 2 чуть-чуть поменяются стили, очень удобно то, что мне не надо придумывать название для нового класса; место, где оно должно храниться; переживать за специфичность; и т.д. и т.п.
Например, какая боль в этом примере, если Content 1 и Content 2 одинаковые, но только надо добавить margin-top второму.
Вы дали пример, где в реальности TailwindCSS сильно выигрывает у классического подхода.
Вот именно про это я и говорю. У Content 2 немного поменялись правила, а ленивый разработчик не захотел давать этому изменению никакой семантики. Поддерживать такой код потом очень сложно как раз из-за отсутствия семантики. И как раз в вашем примере возникает вопрос: если вы второму элементу ставите отступ, то нужно ли будет его ставить последующим элементам, и почему отступ здесь сделан маржином, а не увеличением gap грида? Предположим, двум разработчикам дали параллельные задачи: одному — добавить Content 3, а другому — попроавить отступ. Изменения в реальном проекте скорее всего будут в удалённых друг от друга строках, поэтому мерж-конфликта не будет, но после мержа будет не очень хорошо. В проектах вида «наговнокодил, отдал и забыл» это худо-бедно работает. Опять-таки — это самый простой случай.
Что касается специфичности, то это не должно быть проблемой, потому что излишней специфичности селекторов и так не должно быть.
Насчёт «места, где оно должно храниться» — а тут как раз с этим должна помочь семантика. В большинстве случаев это будет стилевой файл того блока, к которому относится элемент.
Вы же в коде наверняка пытаетесь избавляться от магических констант, а Tailwind, наоборот, поощряет их создание.
Проблема с магическими константами в том, что непонятно, что они значат. И это действительно может быть проблемой, если весь код написан в одном файле на TailwindCSS, – не разберешь, где что.
Но это не проблема, если мы используем компоненты, тогда смыслы мы закладываем в названиях этих компонентов. А как плюс мы получаем возможность не перенагружать смыслами те элементы, которые в них не нуждаются.
Необходимость придумывать название для элемента, только потому что мы хотим задать ему какие-то стили, вынужденная. Стили не всегда имеют смысл. Именно поэтому, например, CSS-in-JS подход (например, styled-components) тоже проигрывает TailwindCSS. Потому что он только усугубляет эту проблему, а не решает её.
На практике это приводит к тому, что разработчики вообще забивают на именование элементов, даже если им нужна семантика. Другой момент — разработчики ленятся искать существующие компоненты и верстают их по месту использования. В отсутствии семантики такое может проскочить ревью, потому что ревьюеры могут не понять, что это за элемент и не предложить использовать уже готовый.
Подход CSS-in-JS тоже плох, но не необходимостью постоянно именовать частные случаи использования компонентов, а перемешиванием кода и стилей. Тогда как постоянное выделение частных стилей свидетельствует об отсутствии системности в дизайне и проектировании компонентов.
Кроме того, подход Tailwind не избавляет от избыточности, если есть некое фиксированное множество наборов атрибутов. Например, стили текстов Heading1, Heading2, Heading3, Primary text, Secondary text. У них могут быть разные гарнитуры, кегли, интервалы и цвета.
Может отпугнуть, если не знаешь, что значат эти классы. Но даже если не знаешь, можно разобраться, если напрячься.
Ничего там не понятно =)
Если одно решение требует что-то зубрить, а второе является вариантом "настроил и забыл", то я выберу второе. Да, с памятью у меня плохо, поэтому предпочитаю не замусоривать её.
Tailwind - это та самая тупая зубрёжка. Впридачу к обычным названиям CSS-свойств нужно вызубрить ещё и их tailwind'овые аналоги, потому что интуитивно все эти названия толком не понятны.
А решение "настроил и забыл" - это CSS modules + SCSS. Один раз настроил webpack и копируешь этот конфиг во все последующие проекты, при этом неважно какой заковыристый там будет дизайн. Ну и придерживаешься порядка при создании компонентов (но это имхо в любом случае нужно).
Лучше выносить в tailwind.config.js
Это одна из странных для меня вещей в тайлвинде.
Цвета/шрифты/отступы/етц в переменных это окей, но почему черт возьми они лежат в конфиге? Конфиг это конфиг, какие-то технические настройки библиотеки. А дизайн-система – это стили, неотъемлемая часть проектного кода, почему она не лежит в src, где-то неподалеку от компонентов?
Ошибки при работе с tailwindcss